Gladius P2P Module Proposal

Gladius is looking to implement our own peer to peer networking solution for our application, we've used others previously that haven't quite fit our needs and we've decided to build our own. Below is a proposal on how we think this should be designed, but we welcome feedback as this isn't just going to be a project for our code, but a general purpose library that other developers can build on top of to create their applications. We've taken inspiration from the Perlin Network's library Noise, so we would like to credit them for some of the design philosophy behind this.

Philosophy

The Gladius P2P Module is going strive to be as agnostic to the purpose of the p2p network as possible. This means we won't be enforcing any type of signature technology, any addressing, or any message structure beyond what is absolutely needed.

Design

Messages

The core of the library will be minimalistic messages. Each message is only required to have a sender, a type, a message, and a checksum field. The message body is left up to the user of the library, and can be signed or unsigned, can be any encoding, or can replicate those fields to be later confirmed by checking the signature.

API

From an API perspective we really enjoyed using Noise, and so we want to continue some of that design in our own application, but obviously with the changes seen in this document.

We're planning on having the below methods to interact with the the network.

Broadcast(message) - Broadcast to all known peers

Broadcast(message, peers...) - Broadcast to these peers specifically

BroadcastRandomly(message, n) - Broadcast to n random peers, useful for anti entropy syncs.

Add(nodeAddress) - Adds a node to the route table

Delete(nodeAddress) - Deletes a node from the route table

NetworkState() - Gets present network state object

RegisterPlugin(plugin) - Registers a user plugin

Listen(address) - Will listen on this address for incoming messages.

Plugins

Every message will be passed to every plugin the user registers, and can be processed based on the type of the incoming message. In our case we will be building a discovery plugin, a latency audit plugin, and a state plugin that uses our existing signature system built on top of Ethereum keys.

We're planning on making the plugin interface look like this, keep in mind that all functions will have access to the network API from above:

NodeAdded(nodeAddress) - Will be called when the network adds a node, this could be through a explicit call to Add by the user or could be from a plugin.

NodeDeleted(nodeAddress) - Could be useful for cleanup, called under same circumstances as NodeAdded

NewMessage(message) - Called when any new message is received by the peer.

Startup() - Called when plugin is initialized

Close() - Called when the network is closed, or plugin is removed.

You can see how something like peer discovery could be built on top of a structure like this, when the first node is added or the network is started, the discovery plugin could reach out to all of the peers it knows and start to send messages to them. The same goes for a state plugin.

Networking

Our code will simply maintain a list of peers and streams, some are writable by default and some are not (this is to allow for potentially unauthorized connections to not be written to unless a plugin specifically wants to). These streams can all be written to by the API exposed above. This gives the developer the flexibility to build most of their discovery as well as message signature systems without having to worry about the networking. We're planning on using KCP to handle the transmission, it will allow us to have fast communication with low overhead, strong encryption support, and the ability to have good reliability.

Add GPL 3.0 Licensing