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.
It has been implemented with forward compatibility by simply ensuring that "*" is never put into the 
 routing cache (so it's always broadcast).
The idea is that if a name is directly equal to "*", it should be broadcast around the local network.
Notably, it is completely incompatible with reliability mechanisms for probably obvious reasons,
 but can still be used in networks running the Reliability Layer via the 'unreliable' escape-hatch.

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.

--- OpenComputers Usage

Copper should be used on port 4957.
Messages should be two part.
The first part should always be "copper",
 the second part should always be the actual data.
All available methods of communication should be open to Copper unless explicitly noted otherwise -
 for example, Linked Cards are one of the methods that could be used for purpose-built wireless links.

--- Overlay Network Usage

In this case, Copper messages may be relayed however the users see fit - but port 4957 UDP messages 
 are a good fit on the basis that they are a parallel.
To prevent annoyed ISPs, the best networking method is a looped daisy-chain.
This provides a bit of redundancy while avoiding ISP-ire-causing mass fanout.
Network messages should be accepted from any IP address, as spoofing is perfectly doable anyway.

--- Serial Port/TCP Usage

Copper packets should just be written out on the connection, prefixed with a big-endian two-byte 
 unsigned integer specifying the size.

--- Hybrid Usage

The connection between OpenComputers and Copper can be performed with a TCP gateway between the 
 Minecraft server and Copper server on the same computer, or via designated Copper HTTP event feeds 
 of some form, or whatever.

It doesn't really matter how the data is transmitted here, since it's just a gateway.
Possibly consider integrating a hierarchial gateway into the OpenComputers/world bridge.