mirror of
https://github.com/XeonSquared/OC-Copper.git
synced 2024-11-08 19:08:05 +11:00
aabbb554c6
In practice it is unlikely that data that's too big for the reliability layer won't need splitting anyway by the application at some point, and the libraries are already too open to OOM DoS.
86 lines
3.6 KiB
Plaintext
86 lines
3.6 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.
|
|
Notably, it is completely incompatible with reliability mechanisms,
|
|
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.
|