Skip to content

Architecture for the release 1

Jump to bottom
Ricardo Tubio-Pardavila edited this page Nov 12, 2013 · 1 revision

Network Architecture

For the release 1, the network elements considered are the following:

  1. The cloud N-System will be composed of a single central server known as the Network Server element, or N-Server for short.
  2. Mission operators (M-Operators) will use the M-Client element to access to the services provided by the central N-Server.
  3. Ground Station operators (G-Operators) will use the G-Client element to access to the services provided by the central N-Server.

Since the objective for this project (in accordance with requirements from AD-1) is to develop only the network definition and implement the required network infrastructure, none of the client elements will be implemented. Only testing applications will be developed for performing tests on the final N-Server element. These testing clients will be distributed, but only for testing issues. Therefore, final users of the network must develop their own clients, even though they may use these testing applications as a starting point.

Figure below depicts this topology for the release 1.

Network topology

The N-Server

The software architecture for this element of the network is composed of the following software components:

  • The WebServices software component, a web application developed under the Django Framework. This web services provide a Graphical User Interface (GUI) to all the users of the N-Server: M-Operators, G-Operators and N-Operator.
  • The Protocol software component that is a Python application daemon running on the Debian OS. This is the software component responsible for exchanging data in between G- and M- software clients.

The utilization of a separated software component for implementing the services offered to software clients, is required in order to reduce the overhead of utilizing an over-HTTP protocol. This way, the protocol daemon can reduce the server response time by using a lightweight TCP based remote protocol and improve the network performance. This protocol will be based in the usage of AMP RPC protocol (TBC), provided by the Twisted Network Framework (see Annex A of this document for further details on the protocol selection).

The utilization of a Web Development Framework like Django will ease the implementation of the user interfaces and the information storage in a database like MySQL. Native database access libraries included in Python will permit an easy-access also to the information of the database by re-using the SATNet Model DB also in the Protocol component.

N-Server architecture

The WebService component is composed of the following libraries, since it must follow the MVC model for the Django Framework:

  • The SATNet DB Model Python package based on the Models of the Django Framework for Python objects direct mapping to a database.
  • A WebServices set of Django applications, with the views and controllers required.

The Protocol component is composed of the following libraries and applications:

  • A NetworkIF Python package with the callback functions for processing the remote calls.
  • A Protocol component that includes the main execution loop for this daemon, together with the link for the usage of the SATNet DB model library. It also holds the runtime data of the application and is responsible for its startup, which involves reading configuration, processing command line arguments, operating system integration and setting up the required logging system.
Clone this wiki locally