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. 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. 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.