| Document Version 21 |  | |
LINX Protocols | ||
| Prev | 7. Enea LINX TCP Connection Manager | Next |
|---|---|---|
With the Enea LINX TCP Connection Manager Protocol, a connection is established in the following manner.
The TCP CM listens on port 19790 by default. Node A wants to connect to node B. A creates a TCP socket and connects it to B, sends a TCP_CONN message and then waits for a randomly amount of time for an acknowledgement. If an acknowledgment is not received, A will restart the connection procedure.
B accepts the socket and when B wants to connect to A, it will lookup the previously accepted socket and read the TCP_CONN header. Then, it will send an acknowledgement TCP_CONN header to A.
B considers the connection established if the send was successful and then notifies the upper layer of the established connection.
A receives the TCP_CONN header and notifies the upper layer of the connection.
If both nodes try to connect to each other at the same time, neither of the nodes will receive an acknowledgment since the headers are sent on different sockets. This will lead to retries of the connection procedure. The timeouts for the retries are random.
The Enea LINX TCP Connection Manager protocol defines the following header and package types.
Table 7.1 TCP Connection Manager Protocol Header Types
| Protocol number | Value | Definition |
| TCP_CONN | 0x43 | Connect type. Used for connection acknowledgement |
| TCP_UDATA | 0x55 | User data type |
| TCP_PING | 0x50 | Keep-alive header type |
| TCP_PONG | 0x51 | Keep-alive response header type |
All messages in the TCP CM protocol have the following header. Only if Type indicates TCP_UDATA the fields source and destination are used - otherwise they must be set to zero. The size field is always used in the TCP_UDATA header and it may also be used in the TCP_CONN header.
Table 7.2 TCPCM Generic Header
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
| Reserved | O | Version | Type | ||||||||||||||||||||||||||||
| Source | |||||||||||||||||||||||||||||||
| Destination | |||||||||||||||||||||||||||||||
| Size | |||||||||||||||||||||||||||||||
Reserved for future use, must be 0.
Version of the TCP CM protocol.
Type of the current packet
Source link id. Used in type TCP_UDATA, otherwise 0.
Destination link id. Used in type TCP_UDATA, otherwise 0.
Size of user data in bytes, followed by the header. Used in type TCP_UDATA and TCP_CONN, otherwise 0.
The two endpoints of a connection send TCP_PING headers to one another every configurable amount of milliseconds (default is 1000). When an endpoint receives a TCP_PING header, it will respond by sending a TCP_PONG header to the peer. If the connection goes down in any way, this will be detected and the CM will report this to the upper layer.