zerotier/sequential-exchange
0
0
Fork 0
mirror of https://github.com/zerotier/sequential-exchange.git synced 2026-05-22 16:28:28 -07:00
Code Issues Packages Projects Releases Wiki Activity

updated readme

Browse Source
This commit is contained in:
Monica Moniot
2023-09-06 15:56:58 -04:00
parent 39ec9b50fb
commit 05e8a62ab3
1 changed files with 5 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+5 -8
View File
@@ -2,24 +2,21 @@
The reference implementation of the **Sequential Exchange Protocol**, or SEP.
SEP is a peer-to-peer transport protocol that guarantees packets of data will always be received
in the same order they were sent. In addition, it also guarantees the sequential consistency of
stateful exchanges between the two communicating peers.
SEP is a lightweight, peer-to-peer transport protocol that guarantees packets of data will be losslessly received by the remote peer, and can optionally guaranteed that specified packets arrive in the order that they were sent. In addition, SEP facilitates stateful exchanges between two peers, giving each peer the opportunity to "reply" to any packet sent by the remote peer. This makes SEP particularly well-suited for writing async-await code, because unlike TCP, SEP will handle multiplexing each reply to the correct awaiter. Even without async-await, a simple `match` statement is sufficient to correctly multiplex packets to their handling code.
A "stateful exchange" is defined here as a sequence of packets, where the first packet
initiates the exchange, and all subsequent packets are replies to the previous packet in the
exchange.
SEP guarantees both peers will agree upon which packets are members of which exchanges,
and it guarantees each packet is received by each peer in sequential order.
exchange. Every exchange can be thought of as a linked list, where the head node is a packet containing a normal payload, and all subsequent nodes are replies to previous nodes. The final node is always a simple acknowledgement packet, or Ack, that signals a given exchange is over. Both peers are guaranteed to agree upon the "topology" of these links. Links will never get crossed, replies will always be received and understood, a peer will never deadlock awaiting a reply, and in general it is much easier to write bug-free networking code.
SEP is a tiny, dead simple protocol and we have implemented it here in less than 500 lines of code.
SEP is transport agnostic, and will not take over an entire UDP socket. As such it is relatively easier to run SEP in parrallel with raw UDP, or even with itself. Multiple instances of SEP can be opened between two peers and communication over each can occur in parrallel, making it very easy to reduce or even eliminate front-of-line latency in performance critical applications.
## Why not TCP?
TCP only guarantees packets will be received in the same order they were sent.
It has no inherent concept of "replying to a packet" and as such it cannot guarantee both sides
of a conversation have the same view of any stateful exchanges that take place.
of a conversation have the same view of any stateful exchanges that take place. This must be implemented manually by the user of TCP.
TCP is also much higher overhead. It requires a 1.5 RTT handshake to begin any connection,
it has a larger amount of metadata that must be transported with packets, and it has quite a few