Data Transfer

This chapter describes a software-based architecture for mirroring data between two TSENTRY-based systems or between a TSENTRY-based system and a third-party box.  This is available as a low cost optional add-in to the standard TSENTRY system.  As opposed to a hardware-based reflective memory solution (e.g. VMIC® reflective memory cards), this design transfers data from one system to another via TCP/IP.  While a hardware-base solution provides much lower latency in terms of the communications between systems, in many cases the high-speed data transfer is unnecessary and thus the lower overhead and simpler design of a software-based solution is more appealing.

Under this architecture a client process on one machine makes a connection to the server on a second machine.  Upon connecting, the client sends a list of variable names and a requested refresh rate.  The server parses this list and responds with the types and sizes of the variables that it found and can return together with the refresh rate at which it will send updates.  After this point the server sends updates for each of the available variables at the specified interval.  A single update consists of the current value of each of the variables packaged into a single telegram so that all variables are updated simultaneously.  The updates continue indefinitely until one side or the other destroys the connection.

In this architecture data transfer is unidirectional.  Data transfer in the reverse direction can be realized by starting a server process on the second machine and configuring a client to run on the first.

The TSENTRY GsmExpSvr process is a multithreaded TCP/IP server that allows remote (or local) clients to connect and request variables from global shared memory segments.  Upon startup it attaches to all TSENTRY global commons and begins to listen for requests.  Much like the trend server TrendSrv, each connection into the GsmExpSvr server spawns a new thread to handle all communications with that particular client.  Associated with each thread is a console window to display diagnostic information about the status of communications.

On systems other than Windows/TSENTRY, a GsmExpSvr server must adhere to the communications specifications laid out below, but otherwise may be designed to suit the particular system.  Such servers have been written for the QNX and Modcomp operating systems.

The TSENTRY GsmExpRcv process is a single threaded application that can request several groups of variables from different machines at different rates.  For each variable both the remote variable name and the local variable name must be specified; if the local variable cannot be found in the data dictionary the receiver will immediately display an error and the process will exit.  An example .ini file is shown below:

# GsmExp configuration file

[GsmExpSvrs]
#Group Name      #IP Address of GsmExpSvr      #SamplePeriod (ms)   #TimeoutFactor
Group1           127.0.0.1                     500                  10
Group2           127.0.0.1                     5000                 10


[Group1]
#Remote variable name            #Local variable name
AFCCO.AfcCounter                 AFCCO.bAfcActive
AFCCO.bAfcModeChg                AFCCO.bAfcModeFinal


[Group2]
#Remote variable name            #Local variable name
AFCCO.bAfcModeOk                 Local2.Var.1
Remote2.Var.2                    AFCCO.bAfcSetup

In addition to the standard variable types (character, 2-byte integer, 4-byte integer, 8-byte integer, 4-byte float, and 8-byte float), complex data types such as structures and/or arrays may be transferred between the two systems.  In these cases simply specify the variable name as the name of the desired structure or array (without undefined array index braces) within global common.

On systems other than Windows/TSENTRY, a GsmExpRcv client must adhere to the communications specifications laid out below, but otherwise may be designed to suit the particular system.  Such clients have been written for the QNX operating systems.

1. The client establishes a connection to the server

2. The client sends list of parameters as an ASCII string delimited by ampersands and terminated by a carriage return:

per=<desired sampling period>&vars=<variable #1 name>,<variable #2 name>,...,<variable #n name>\r

3. The server responds with the true update rate and the size of each variable that will be returned:

1 byte = STX 0x02
3 bytes = all zero
4 bytes = number of bytes in this message from STX to ETX, inclusive
4 bytes = message type = 0x00000000
4 bytes = true sampling period in milliseconds in long integer format
2 bytes = fundamental type for variable #1
2 bytes = both zero
4 bytes  = number of bytes for variable #1 in long integer format (a)
2 bytes = fundamental type for variable #2
2 bytes = both zero
4 bytes  = number of bytes for variable #2 in long integer format (b)
…
2 bytes = fundamental type for variable #n
2 bytes = both zero
4 bytes  = number of bytes for variable #n in long integer format (n)
1 byte = ETX 0x03

 4. The Server the begins to send periodic updates to the binary data. Each update is formatted as:

1 byte = STX 0x02
3 bytes = all zero
4 bytes = number of bytes in this message from STX to ETX, inclusive
4 bytes = message type = 0x00000001
4 bytes = seconds timestamp for current data in long integer format
4 bytes = nanoseconds timestamp for current data in long integer format
a bytes = binary data for variable #1
x bytes = blank bytes to put following variable on 4 byte boundary
b bytes  = binary data for variable #2
x bytes = blank bytes to put following variable on 4 byte boundary
…
n bytes  = binary data for variable #n
x bytes = blank bytes to put following byte on 4 byte boundary
1 byte = ETX 0x03

5. The connection is closed

1. If the server is unable to locate a requested variable, it shall return a zero for the size.  Consequently, in the periodic updates it will be completely excluded.  It is up to the client to decide how it wants to handle this scenario, i.e. accept only a subset of desired data or kill connection.

2. If the server is unable to parse a valid request from the initial message in step 2 above, it shall respond with a NAK message:

1 byte = STX 0x02
3 bytes = all zero
4 bytes = number of bytes in this message from STX to ETX, inclusive
4 bytes = message type = 0xFFFFFFFF
1 byte = ETX 0x00