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 1507 bytes long. 1500 in-relib data bytes + 7 relib bytes. This makes the user's life easier by having an easy to remember MTU from within relib of 1500 bytes. 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. ERRATA: The data MTU was described as 1506 bytes due to an error in the protocol.2 document. It should be 1507 to fit 1500 relib byets and the 7-byte header.