61 lines
2.3 KiB
Groff
61 lines
2.3 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 6-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.
|
|
|
|
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.
|