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.
41 lines
1.6 KiB
Plaintext
41 lines
1.6 KiB
Plaintext
Copper Protocol
|
|
20kdc, 2017
|
|
|
|
Copper is a simple to implement networking protocol based on names.
|
|
This is it's sole purpose.
|
|
It can be used in various contexts, though it is not suitable as a
|
|
secure peer-to-peer networking protocol where all actors are untrusted.
|
|
|
|
Rather, Copper is better for the situation of the current internet -
|
|
hierarchial structures (operated by semi-trusted parties, with
|
|
encryption used to hide information from them as appropriate),
|
|
with arbitary network structure at the fully-trusted-network level.
|
|
|
|
Copper addresses are names.
|
|
In the context of a system not implementing a hierarchial gateway,
|
|
this is as much about Copper addressing as matters.
|
|
|
|
Copper base packets contain 4 fields.
|
|
One byte indicating how many nodes have retransmitted the message
|
|
(the original sender should use 0),
|
|
A name (as a length-minus-1-byte-prefixed-string),
|
|
another name (in the same format),
|
|
and the rest is data.
|
|
|
|
Copper packet data may be up to 1506 bytes long -
|
|
this does not include header data, which may be up to (256*2) + 3 bytes long.
|
|
|
|
Loop detection should performed by checking if a packet exactly the same has
|
|
been seen recently - other rejection, alteration and routing measures
|
|
are up to the implementer.
|
|
|
|
Signalling is inadvisable - Copper is primarily meant to allow creating
|
|
internally "partyline" OpenComputers in-game networks with named nodes
|
|
and some semblance of routing or structure.
|
|
|
|
Should a situation be dire enough,
|
|
hierarchial networks (described in file 2, 'protocol.1'),
|
|
and custom routing software in general,
|
|
can be used to split networks however the system requires.
|
|
|