mirror of
https://github.com/XeonSquared/OC-Copper.git
synced 2024-11-08 19:08:05 +11:00
47ec74bc89
The previous testcase was "all nodes communicating randomly", basically a worst-case. This testcase is somewhat more realistic, a set of nodes communicating between each other via other nodes, a given TO node recurring once every 5 seconds (approximately). Notably, the 'packet transfer total' figure should be halved, as in the testcase pings and responses are used, but only responses are counted.
93 lines
3.4 KiB
Groff
93 lines
3.4 KiB
Groff
Copper Protocol :: Reliability/Fragmentation 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
|
|
be up to 22,500 bytes in size, though a fragment can only be up to 1500 bytes.
|
|
|
|
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.
|
|
|
|
The upper nibble indicates the amount of fragments in the packet - 0
|
|
indicates an acknowledgement.
|
|
The lower nibble indicates which fragment this is, or if this is an
|
|
acknowledgement, which fragment was acknowledged.
|
|
|
|
0x0F indicates that this is a *deliberately* unreliable packet.
|
|
(These packets cannot be fragmented or acknowledged, and thus have the
|
|
per-fragment limit of 3993 bytes.
|
|
The attempt number and primary packet number still have meaning.)
|
|
|
|
Two example scenarioes will now be presented:
|
|
|
|
1.
|
|
|
|
ARCHWAYS sends a 0x10 'First fragment of a one fragment packet' to
|
|
IWAKURA on port 8080, twice (the first attempt being dropped).
|
|
1F 90 | F4 21 B9 | 00/01 | 10 | (...)
|
|
port packetID Attempt CC Data
|
|
|
|
IWAKURA receives it successfully on the second time, and sends back a
|
|
response, three times.
|
|
1F 90 | F4 21 B9 | 00/01/02 | 00
|
|
port packetID Attempt CC
|
|
|
|
ARCHWAYS receives the response and does not send a third packet.
|
|
|
|
2.
|
|
|
|
IWAKURA, having parsed the packet, sends back a long response on the same port.
|
|
The response is two packets long.
|
|
1F 90 | 91 19 28 | 00 | 20 | (...)
|
|
1F 90 | 91 19 28 | 00 | 21 | (...)
|
|
|
|
ARCHWAYS receives both packets, in the wrong order
|
|
(but it reassembles it anyway), and ACKs three times...
|
|
...but the packets are dropped due to a crow getting in the way of the
|
|
satellite dish at the wrong point. Blasted crow.
|
|
|
|
1F 90 | 91 19 28 | 00/01/02 | 21
|
|
1F 90 | 91 19 28 | 00/01/02 | 20
|
|
|
|
IWAKURA, waiting, say, 6 seconds
|
|
(assuming ACKs are sent a second and a half apart) sends a retransmission.
|
|
|
|
1F 90 | 91 19 28 | 01 | 20 | (...)
|
|
1F 90 | 91 19 28 | 01 | 21 | (...)
|
|
|
|
ARCHWAYS ACKs the retransmission, just in case - this works.
|
|
|
|
1F 90 | 91 19 28 | 00/01/02 | 21
|
|
1F 90 | 91 19 28 | 00/01/02 | 20
|
|
|
|
IWAKURA's application knows the message got through.
|