Project

Detailed information about the project as a whole, in addition to all of the component subprojects. Technical overviews, project status updates, protocol specifications, and user guides will all live here as they become available.

Project < Relay Protocol

The relay protocol is a foundational networking protocol that aims to "replace" TCP and UDP by extending the pattern of nested header and data blocks found in the lower level network protocols into arbitrarily higher layers of the protocol stack. (In practice, replacing TCP/UDP is nearly impossible, so Relay ends up integrating those protocols.) It achieves this by defining a protocol for layered protocol stacks, where each layer of the protocol stack can also be negotiated by the two peers making a connection. This allows rapid protocol evolution and backwards compatibility.

Design Goals

Coming Soon.

Relay Specification

(DRAFT)

A Relay message has an arbitrary number of layers, where each layer has a source and destination state (like a source and destination IP address or port number), in addition to a source and destination protocol id. The destination fields allow each layer of the protocol to distinguish the channel it is operating on as well as the next protocol that the data payload should be routed to, while the source fields allow responses to be sent without agreeing on a shared channel identifier. For example, a TCP/IP packet is identified in this way: an IP layer that contains a source and destination IP address (the protocol “state”) in addition to the next protocol’s identifier (pointing at TCP), and the TCP layer again contains some state via the source and destination port numbers.

However, this is where this pattern traditionally ends, and is where the Relay protocol picks up. Relay allows more layers to be added beyond TCP/UDP ports, and also defines behavior for two nodes to negotiate from a choice of protocols. So instead of just choosing an IP address and TCP/UDP port, software can create a protocol tree proposal that covers several different ways for the communication to meet its needs. Instead of relying on “fat” protocols like TCP or QUIC, you can compose the needs for transmission on the fly: authentication, multiplexing, encryption, and packet ordering can each be their own layer, mixed and matched as needed. And due to the protocol negotiation capabilities, protocol evolution is easy to roll out in a backwards compatible way.