The advantage of a server type module
The clear advantage of using a server is to have a gate to control the parameter data flow and to make possible the share of these packages among the software clients.The server is based on a main connection to the Flight Gear Simulator and several other connections to the clients.
The network connection between the server and the Simulator is established by use of TELNET protocol, over TCP/IP. The TELNET protocol specifications are available for instance in RFC854 document http://www.faqs.org/rfcs/rfc854.html
This means that the Data Server is making requests that are translated to TELNET commands, these commands are sent through the outcome flow and finally the Flight Gear Simulator will convert them to internal commands.
The specified parameters are checked and the values are sent back to the server through the outcome flow of the Simulator, the equivalent of the income flow of the Data Server.
The reason of including the server
The efficiency of the modules system consists in the possibility of having more than one client which is dedicated to the analyse of the data. In addition to this some other processing tasks are integrated in the server. This means that one client will have more processing power for accomplish the right steps for the analyse.
Hidden connections.The data flux over
the TELNET
First of all the user must make a selection in the available parameter list. This means that the server will get the selected parameters continually as soon as the data flows are created.
The first step to follow by the server is to try to make a connection to the Flight Gear Simulator. For this the IP address of the computer on which the Simulator is running is needed. If the IP address does not corespond to a station with a running instance of Simulator, a notice on the attempt failure is showed. The other parameter would be the port number on which the Simulator is waiting for connections.
Although this can be set on wish at the start of the Simulator by using a sequence like: --props=socket,bi,5,localhost,5555,tcp, it is an internal thing of the program set to the value of 5555 so as not to put the user to fix every time the parameter.
As soon as the server has a connection to the Simulator, an income and outcome flows are created and the comunication can take place. There are some classes specially designed for the hight level use of Telnet comunication methods. At a certain point the programmer can call a method having as an argument a string parameter which would stand for the name of the wanted flight parameter to be got from the flight context.
As soon as the request was sent, the data server may wait to receive the value of the parameter. For that the server has an additional thread attached to each income data flow. The main goal of that thread would be to run a blocking method which would wait until some data commning from the other end of the connection are available.
The procedure is repeated for each parameter in the selected parameter list.
After a parameter value is received it is stored in the internal memory of the server.
There is a situation that must be discussed. This is related to an inconsistency of the data manipulation and can occur when a request for any parameter values is rised by a client. In this situation the server must check to see whether the procedure of getting the all set of parameter from the Flight Gear Simulator is finished. Otherwise it would be possible to have parameter values from the previous situation still in the memory and at the same time some other parameter values from the current situation. This kind of inconsistency is solved by using a boolean variable.
Before the start of the request sending this variable is set so as to denote the state of data inconsistency and as soon as the process is finished, this variable will be set back to initial value. Just from this point the values can be read from the server's memory and sent to the clients.
It is important to notice that the time delays occured in the system are forward chained. The main delay occur at the values from the Flight Gear Simulator to the Data Server. This is mainly because of the slowness of the procedures related to the TELNET protocol. During this time of getting the values no client can receive the parameter package.
Specific tasks to accomplish.Blackboard
The system of parameter values gathering is the main task inside the Data Server. The other components are related to the comunication with the clients. The blackboard system is specially designated to store the value of each paratemeter from the selected list for a long period of time.
The use of the parameter values history is possible on the side of each client analyser by sending a request to the Data Server. For every received request, the Data Server is reading the list of values of the parameter from the hard disk and is sending it to back to the client.
The Blackboard module is integrated in the Data Server. This is however not a good way because there are a few disadvantages.
Although the advantage would be to have the Blackboard near the system of threads and the memory of parameter values and this making to shorten the overall delays, it also leads to overloading the income/outcome data flow between the server and each client.
Moreover it is again about the processing power that it is supposed to be as distributed as possible. More about this are discussed in the section of proposed improvements.