...
Please note that since namespacing hasn't been finalized, yet, much of this is subject to change when the namespace-related duties of the communication layers are decided. Of particular interest are the effects that namespaces might have on which remote nodes get included in a node's peer group.
Wire Protocol
For all structured, protocol messages, the wire format is serialized protocol buffers. This is a thoroughly debugged, forwards-compatible message format, and there is a protocol buffer implementation for nearly every major language and no few minor ones.
...
This lack of rich type information in serialized protocol buffers, although yielding good network performance, is not without its annoyances. An protocol buffer of unknown type cannot be deserialized upon receipt; the receiver must assume its type. This leads to the use of a union-type pattern in protocol design. Moreover, there is no native framing protocol, so messages cannot be streamed effectively without cobbling together one of your own. Finally, if protocol version is important, it must be included explicitly as part of a message.
Overlay Network
Like Ethereum, RChain borrows the peer-to-peer mesh overlay from BitTorrent and other file-sharing technologies. The current implementation in RChain is based on the parts of the Kademlia protocol that establish and maintain a view of some subset of the network (a node's peers). This is described in more detail here.
Each peer included in the network overlay for a particular node may carry subjective measures. These include reputation, a measure of how well the peer is performing the duties from the protocol perspective. Also included might be metric information about latency to this node or measured throughput (if doing large transfers, for instance). These measures may be used for a number of reasons. A node may wish to replace underperforming peers. Alternatively, a node may wish to pick a certain number of the best performing peers to use in a validation subnet.
Peer-to-Peer Protocol
There is a need for security and compatibility testing above the basic mesh overlay, so that peers which are either incompatible (running too-old versions of the software, for example) or which are simply unfamiliar with the cryptographic protocols in RChain (running different or malicious software, say) are not joined to the node's view.
Belonging in this layer, but not yet implemented, is filtering based on namespace interests. If a validator's view of the network should be limited to other nodes interested in processing transactions from the same or related namespaces, this should form part of a potential peer's inclusion-or-exclusion decision.
Other RChain Protocols
For consensus and any other activity under the control of the nodes themselves, a more direct, connected, reliable topology may be required. Currently, a ZeroMQ-based communications object is implemented to fill that role. ZeroMQ is not required but simplifies a number of network-programming chores, including reconnection and buffering. However, those characteristics that make it easy to program network-aware applications using ZeroMQ argue against exposing it to higher layers in the RChain node code, since they are also useful tools in carrying out denial-of-service or other resource-exhaustion attacks.
ZeroMQ imposes few, if any, restrictions on the form that communication takes. It provides enough of a framing protocol that in combination with protocol buffers, the communication needs of a robust consensus protocol like Casper could be met. If the overhead imposed by a message queuing system is too high, the system could simply use a less reliable, connectionless transport like UDP, as a sort of optimistic communications layer.
External Network Communication
If RChain is to support connection to and communication with nodes that may not even be part of the RChain peer network, then clearly these connections cannot be part of any peer-to-peer networking overlay. As such, the current plan is to implement these connections directly, but within a different part of the communications layer.
...