1
0
mirror of https://github.com/XeonSquared/OC-Copper.git synced 2024-11-08 19:08:05 +11:00
OC-Copper/protocol.0

53 lines
2.1 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.
--- The Broadcast Address
The Broadcast Address is a possible feature which may or may not be actually used.
For now it is not implemented.
The idea is that if a name is directly equal to "*", it should be broadcast around the local network.
Hierarchial gateways do not need modification on the from-child rules
("*" is local to them there,
"<*" or such is dealt with correctly by the normal rules),
but in the from-parent rules it may be desirable to forward "*" to child networks.
Or not.