...
The communications within the system are based on transactions over TCP, established between a Client (any control window on a console) and a Server (any DEVIL).
When a Client opens a connection with a Server, this launches a dedicated program (Servlet) that handles all the requests incoming coming from that Client.
Many Clients can open simultaneous connections with the same DEVIL; in this case the DEVIL will launch launches — and hold on — many Servlet instances that will operate concurrently.
The connection relies on TCP/IP native transaction protocol — within a LabVIEW process — with no application handshake:
...
The TCP connection terminates automatically when the Client stops, that is , the control window closes or the LabVIEW process quits (or even crashes). Should any of these condition occur, the corresponding Servlet quits by itself.
...
Once the connections has been established, the Client asks the Server to do something or to return some data by mean of a specific application protocol named TCP_DCS.
The Client sends always Command packets and the Server answers with Ok packets, Result packets or Error packets.
Both commands from a Client and answers from the Server always starts with a Header packet.
The Header packet will not be shown in the following description; think of it as always there. But logically, it Logically the Header packet, "precedes the packet" rather than "is being included in the packet" (See fig. 1).
Fig. 1 - Structure of a command packet.
| Code Block | ||||
|---|---|---|---|---|
| ||||
Bytes Name ----- ---- 4 packet Length 4 Transaction ID 4 Unit ID |
- packet length: the length, in bytes, of the packet that follows the Header packet.
- Transaction ID: a number that can be used to validate the transaction.
- Unit ID: a number that can be used to select some action at the application level.
| Code Block | ||
|---|---|---|
| ||
Bytes Name ----- ---- 4 opcode n arguments |
- opcode: a unique number associated to the specific service.
- arguments: any data (string or binary stream) needed for the execution of the command (e.g. element name, set value, etc...) The arguments size can be calculated from the packet length as: arguments size = (packet length) - 4
Opcode | Name | Associated function and parameters |
0x00000000 | DO_NOT_USE | 0x00000000 must NOT be used |
0x00000001 | FETCH | fetch the STA or DYN fork: <elementName>,STA|DYN |
0x00000002 | SEND CMD 1 TO 3 | send a command from the console to the DEVIL: <command_string> |
0x00000003 | FETCH_BUFFER | fetch n bytes from a buffer global variable: <#OfBytes> |
0x00000004 | ECHO | send n bytes ang get the same n byte back: <byte_string> |
0x00000005 | FETCH_BLOCK | fetch STA or DYN fork (full array): <elementName>,STA|DYN (the elementName is used by the servlet just to recognize the proper class and can be any elementName belonging to that class in that DEVIL) |
0x00000006 | GET_ALIVE_COUNT | read the DEVIL alive counter: no arguments |
0x000000xx | to be defined | to be defined |
0x000000ff | DO_NOT_USE | 0x000000ff must NOT be used |
...
| Code Block | ||
|---|---|---|
| ||
Bytes Name ----- ---- 4 packet code, always = 0x00000000 |
...