mirror of
https://github.com/XeonSquared/OC-Copper.git
synced 2024-11-10 03:48:05 +11:00
aabbb554c6
In practice it is unlikely that data that's too big for the reliability layer won't need splitting anyway by the application at some point, and the libraries are already too open to OOM DoS.
59 lines
2.2 KiB
Groff
59 lines
2.2 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.
|
|
|
|
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.
|