izaya/OC-Copper
1
0
Fork 0
mirror of https://github.com/XeonSquared/OC-Copper.git synced 2024-11-14 22:08:05 +11:00
Code Issues Releases Wiki Activity
2c13ad9469
OC-Copper/protocol.2

59 lines
2.2 KiB
Groff
Raw Normal View History

Remove the fragmentation part of the reliablility layer 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.
2017-03-19 02:31:25 +11:00
Copper Protocol :: Reliability Layer
Add incomplete workspace, for now.
2017-03-18 20:34:13 +11:00
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
Remove the fragmentation part of the reliablility layer 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.
2017-03-19 02:31:25 +11:00
only be up to 1500 bytes precisely. This value does not change.
Add incomplete workspace, for now.
2017-03-18 20:34:13 +11:00
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.
Lowered protocol packet size limit and changed how it's calculated, also changed testcase to be slightly less worst-case. 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.
2017-03-18 23:28:46 +11:00
Reliability Layer packets have a simple 6-byte header.
Add incomplete workspace, for now.
2017-03-18 20:34:13 +11:00
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.
Remove the fragmentation part of the reliablility layer 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.
2017-03-19 02:31:25 +11:00
The final header byte is the actual indicator of what is in the packet.
Add incomplete workspace, for now.
2017-03-18 20:34:13 +11:00
Remove the fragmentation part of the reliablility layer 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.
2017-03-19 02:31:25 +11:00
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.
Add incomplete workspace, for now.
2017-03-18 20:34:13 +11:00
Remove the fragmentation part of the reliablility layer 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.
2017-03-19 02:31:25 +11:00
An example scenario will now be presented:
Add incomplete workspace, for now.
2017-03-18 20:34:13 +11:00
1.
Remove the fragmentation part of the reliablility layer 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.
2017-03-19 02:31:25 +11:00
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
Add incomplete workspace, for now.
2017-03-18 20:34:13 +11:00
Remove the fragmentation part of the reliablility layer 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.
2017-03-19 02:31:25 +11:00
Bob receives it successfully on the second time, and sends back a
Add incomplete workspace, for now.
2017-03-18 20:34:13 +11:00
response, three times.
Remove the fragmentation part of the reliablility layer 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.
2017-03-19 02:31:25 +11:00
1F 90 | F4 21 B9 | 00/01/02 | 02
port packetID Attempt PT
Add incomplete workspace, for now.
2017-03-18 20:34:13 +11:00
Remove the fragmentation part of the reliablility layer 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.
2017-03-19 02:31:25 +11:00
Alice receives the response and does not send a third packet.
Reference in New Issue Copy Permalink