109 lines
4.4 KiB
Groff
109 lines
4.4 KiB
Groff
Copper Protocol :: Reliability Layer
|
|
20kdc, 2017
|
|
|
|
The Copper Protocol as described in files 1 and 2 does not have any
|
|
semblance of application multiplexing or failure recovery.
|
|
|
|
This is intentional.
|
|
Assuming that nobody is trying to make the fatal mistake of constructing
|
|
a NAT, files 1 and 2 are enough for all routing-related purposes.
|
|
|
|
For applications, however, a protocol must be layered on top.
|
|
|
|
This document on the Reliability Layer describes how that should work.
|
|
|
|
All implementations of Copper that synthesize their own packets SHOULD
|
|
follow this protocol when doing so, unless they are a custom system
|
|
that will not be connected to any global network.
|
|
|
|
Firstly, note that, to the application, a Reliability Layer packet can
|
|
only be up to 1500 bytes precisely. This value does not change.
|
|
|
|
Secondly, note that an application should be able to ask to be notified
|
|
when a packet is received successfully or when the implementation gives up,
|
|
with a flag indicating which is which.
|
|
|
|
Reliability Layer packets have a simple 7-byte header.
|
|
The first two bytes are the port number, in big-endian format.
|
|
The next three bytes are a number to this application-side packet.
|
|
They should be as random as possible.
|
|
The next byte is the 'attempt number' - the amount of attempts by this
|
|
side of the Reliability Layer "connection" to send a packet with this
|
|
meaning.
|
|
|
|
This can be achieved serially or otherwise, but should have a random base.
|
|
Combined with correctly-forgetting packet caches, this should prevent
|
|
any packets lost by data collision.
|
|
|
|
The final header byte is the actual indicator of what is in the packet.
|
|
|
|
There are two sections of packet types:
|
|
|
|
-- Basic Datagrams
|
|
|
|
0x00 indicates that this is an unreliable packet.
|
|
0x01 indicates that this is a reliable packet, expecting acknowledgement.
|
|
0x02 indicates that this is an acknowledgement for a reliable packet.
|
|
Other packets should be ignored as far as information is concerned,
|
|
but as for routing-wise, not dropped.
|
|
|
|
An example scenario will now be presented:
|
|
|
|
1.
|
|
|
|
Alice sends a 0x01 reliable packet to Bob on port 8080,
|
|
twice (the first attempt being dropped).
|
|
1F 90 | F4 21 B9 | 00/01 | 01 | (...)
|
|
port packetID Attempt PT Data
|
|
|
|
Bob receives it successfully on the second time, and sends back a
|
|
response, three times.
|
|
1F 90 | F4 21 B9 | 00/01/02 | 02
|
|
port packetID Attempt PT
|
|
|
|
Alice receives the response and does not send a third packet.
|
|
|
|
-- Connections
|
|
|
|
0x03 : Request Connection Start
|
|
This is similar to an 0x01 reliable packet expecting acknowledgement in how it is to be sent,
|
|
including the usual packetID randomization, and multiple attempts.
|
|
However, the data must be two bytes, and these first two bytes must be the new port number.
|
|
The port numbers that ought to be used for active connections are 0x8000 to 0xFFFF.
|
|
The response must be on that port number.
|
|
|
|
0x04 : Request Connection Start / Response
|
|
This is sent on the port given by a Request Connection Start to accept the connection.
|
|
It has the same format as 0x03 (new port number).
|
|
This establishes the connection, and data transmission can begin.
|
|
Connections die if no packets have been received by either side for at least 60 seconds.
|
|
It is recommended the connection "ping" every 15 seconds.
|
|
|
|
- The following packets have the current sequence number as their packetID.
|
|
This variable is per-connection-side, starts at 0,
|
|
and is incremented after a Connection Data packet
|
|
sent by that side.
|
|
|
|
0x05 : Connection Data
|
|
If 0 bytes, this serves as a ping (not a packet)
|
|
The sender's sequence number is incremented by 1 before sending.
|
|
The reply is a Connection Acknowledgement with the same sequence number (but no data)
|
|
|
|
0x06 : Connection Resequencing
|
|
Specifies that the next data packet's sequence number is going to be 0.
|
|
(The packet has the current sequence number, to put it in context.)
|
|
It is this in particular which requires connections keep:
|
|
1. A map of sequence number -> data (flushed when data is read)
|
|
2. A list of sequence numbers to read.
|
|
When ready, a connection data acknowledgement should be given with sequence number 0.
|
|
|
|
0x07 : Connection Data Acknowledgement
|
|
Sent from the target of 0x05/0x06 to the sender. For 0x05, has the sequence number of the associated data.
|
|
|
|
ERRATA:
|
|
|
|
When this document was originally posted, the relib header was described as 6 bytes despite a total of 7 bytes being specified.
|
|
Thanks to @skyem123 for finding the issue.
|
|
|
|
The "Connections" section is a recent extension (August 28th 2017)
|