doc: describe connection reset and disconnect packets
This commit is contained in:
parent
159c3f1518
commit
0309c042e4
|
@ -405,15 +405,71 @@ The following Configuration Types are defined:
|
|||
If the client receives an unknown Configuration Type the corresponding block shall be skipped.
|
||||
The remaining blocks shall be parsed as usual.
|
||||
|
||||
=== Ideas
|
||||
===== Connection Reset
|
||||
|
||||
To be defined:
|
||||
A Connection Reset is set by the digipeater if it receives unexpected packets from stations that are not connected.
|
||||
|
||||
- connection establishment procedure (request, response)
|
||||
- how do clients get an IP(v6) address? -> should be derived from the call sign
|
||||
- when are new clients allowed to connect? -> base station calls for any new stations in regular intervals
|
||||
- handling of packets from unknown clients that are not connection requests
|
||||
- signal quality handling
|
||||
The layer 2 header is filled as follows:
|
||||
|
||||
- Message Type: `001` (Connection Management)
|
||||
- TX Request: `1` if this is the last packet in the burst, `0` otherwise
|
||||
- Source Address: the digipeater’s HAM-64 address
|
||||
- Destination Address: the new client’s HAM-64 address
|
||||
- TX sequence number: reserved, always 0
|
||||
- RX sequence number: reserved, always 0
|
||||
|
||||
The message contains exactly 1 data byte: `0x03` to indicate that this is a Connection Reset packet.
|
||||
|
||||
A Connection Request is sent in a regular burst and can be in any position.
|
||||
|
||||
This message means that the digipeater does not have any information about a connection with the addressed client.
|
||||
Therefore, when a client receives a Connection Reset, it shall drop its complete connection state and start a new connection procedure if desired.
|
||||
|
||||
===== Disconnect Request
|
||||
|
||||
A Disconnect Request is set by the digipeater when it wants to orderly shut down a client connection.
|
||||
It is the last packet that the digipeater sends in a connection.
|
||||
|
||||
The layer 2 header is filled as follows:
|
||||
|
||||
- Message Type: `001` (Connection Management)
|
||||
- TX Request: `1` if this is the last packet in the burst, `0` otherwise
|
||||
- Source Address: the digipeater’s HAM-64 address
|
||||
- Destination Address: the client’s HAM-64 address
|
||||
- TX sequence number: as counted in the connection
|
||||
- RX sequence number: as counted in the connection
|
||||
|
||||
The message contains exactly 1 data byte: `0x04` to indicate that this is a Disconnect Request packet.
|
||||
|
||||
A Disconnect Request is sent in a regular burst and can be in any position.
|
||||
The sequence numbers are sent and handled the same way as in regular connection packets.
|
||||
|
||||
When a client receives a Disconnect Request, it may transmit the remainder of its current queue, but must not queue new data packets.
|
||||
After the last packet is transmitted, the client shall send a Disconnect packet, which confirms the end of the connection.
|
||||
|
||||
The digipeater must keep the connection state in memory until either the Disconnect packet is received from the client or the connection times out.
|
||||
|
||||
===== Disconnect
|
||||
|
||||
A Disconnect packet is sent by the client to terminate the connection.
|
||||
It is the last packet in a connection and is not confirmed by the digipeater.
|
||||
|
||||
The layer 2 header is filled as follows:
|
||||
|
||||
- Message Type: `001` (Connection Management)
|
||||
- TX Request: `0`
|
||||
- Source Address: the client’s HAM-64 address
|
||||
- Destination Address: the digipeater’s HAM-64 address
|
||||
- TX sequence number: as counted in the connection
|
||||
- RX sequence number: as counted in the connection
|
||||
|
||||
The message contains exactly 1 data byte: `0x05` to indicate that this is a Disconnect packet.
|
||||
|
||||
A Disconnect is sent always as the final packet of a burst.
|
||||
The sequence numbers are sent and handled the same way as in regular connection packets.
|
||||
|
||||
When the digipeater receives a disconnect packet in the regular packet flow (i.e. no previous packets are lost), it will immediately drop the connection state and not call this client again.
|
||||
Therefore, if the client wants to ensure that all previous packets are transmitted, it must wait until the digipeater confirms that by sending the corresponding RX sequence number before sending the Disconnect packet.
|
||||
|
||||
=== Message Sequence Charts
|
||||
|
||||
|
|
Loading…
Reference in a new issue