OC-Copper/protocol.0

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.