| Document Version 21 |  | |
LINX Protocols | ||
| Prev | 9. Enea LINX Shared Memory Connection Manager | Next |
|---|---|---|
All SHMCM packets starts with a main header, followed by either a connection header or a user data header. Connection packets are used to setup, supervise and tear-down a connection. User data packets are used to transfer data from protocol layers above the connection manager. All protocol headers must be sent in network byte order.
All packets sent from the shared memory connection manger (SHMCM) starts with MAIN header.
Packet type. Protocol version 1 only supports two types of packets, CON_PKT (1) and UDATA_1_PKT (2).
Packet size. Number of bytes that the packet consist of, including the main header.
Connection packets or CON_PKTs are used to setup, supervise and tear down a connection.
Table 9.2 SHMCM CON_PKT 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 | ||||||||||||||||||||||||||||
| Type | |||||||||||||||||||||||||||||||
| Cno | Spare | ||||||||||||||||||||||||||||||
Connection packet type. Protocol version 1 defines four different packets, CON_REQ (1), CON_ACK (2), CON_RST (3) and CON_ALV (4).
Connection generation number. See Connection Generation Number.
Not used, should be set to zero.
User data packets or UDATA_1_PKTs are used to send data from the upper layers over the connection. The "user data" is located immediately after the UDATA_1_PKT header.
Table 9.3 SHMCM UDATA_1_PKT 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 | ||||||||||||||||||||||||||||
| Cno | Msgid | ||||||||||||||||||||||||||||||
| Src | |||||||||||||||||||||||||||||||
| Dst | |||||||||||||||||||||||||||||||
| Size | |||||||||||||||||||||||||||||||
| Address MSB | |||||||||||||||||||||||||||||||
| Address LSB | |||||||||||||||||||||||||||||||
Connection generation number. It is used to detect and discard "old" user data.
Message id. It is used to keep fragmented user data together.
Source address. CM does not modify this field.
Destination address. CM does not modify this field.
User data size. CM does not modify this field.
Not used in protocol version 1.
Not used in protocol version 1.
The SHMCM consider shared memory to be reliable, i.e. packets will not be lost and they are always received in the same order that they were sent by the peer. The protocol design requires that these two characteristics are fulfilled.
The protocol uses four types of connection packets, listed below, to establish, supervise and tear down a connection.
Table 9.4 SHMCM CON_PKT types
| Protocol number | Value | Definition |
| CON_REQ | 1 | This packet is sent to start connection setup. |
| CON_ACK | 2 | This packet is sent as a reply to a CON_REQ. |
| CON_RST | 3 | This packet is sent to the peer to abort the connection setup or to gracefully tear down the connection. It is not allowed to send user data after that a CON_RST has been sent. |
| CON_ALV | 4 | Once the connection is setup, this packet is sent periodically to indicate that "I'm alive". |
When the SHMCM receives the connect down call
from RLNH, it sends a CON_REQ to the peer and waits for a CON_ACK from
the peer. When the SHMCM receives the CON_ACK, it calls the
connected up call to notify RLNH that the
connection is up. If the SHMCM receives a CON_REQ instead of a CON_ACK,
it replies with a CON_ACK and calls
connected.
If the SHMCM receives a CON_ACK at this point, it should ignore
the CON_ACK. However, if the SHMCM receives a CON_RST or a CON_REQ, it
should call the disconncted up call to notify RLNH
that the connection is down. In case that a CON_REQ was received, the
SHMCM must send a CON_RST before calling
disconnected.
When the connection has been established, it should send CON_ALV
periodically to tell the peer that "I'm alive". If the SHMCM has not
received any packets, CON_ALV or user data, from the peer for a defined
period of time, it should consider the peer dead and disconnect the
connection, i.e. send a CON_RST and call
disconnected.
If the SHMCM receives the disconnect down
call from RLNH, it should send a CON_RST and call
disconnected up call. Also, if the SHMCM encounters
an internal error, it should send a CON_RST (if possible) and call
disconnected.
The SHMCM should have a 16-bit counter that is incremented before a CON_REQ is sent. This number should be included in all packets. The peer should store the counter value, that is received in a CON_REQ/CON_ACK, and compare it with the one that is included in the packets. If they differ, the packet should be discarded.
The SHMCM gets the user data and corresponding meta-data in the
transmit down call. The user data is packed into
one or more UDATA_1_PKTs and sent to the peer. If more than one packet
is required, an ID tag (msgid) should be added to the packets so that
the peer can identify which fragments that belongs together and
re-assemble them.
The SHMCM should use the size fields in the main header and the user data header to determine if the user data has been split into several UDATA_1_PKTs.