94 lines
4.1 KiB
Plaintext
94 lines
4.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 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.
|