redpine-rs

Redpine is a connection-oriented UDP messaging library. It provides automatic fragmentation, reliable delivery, congestion avoidance, and robust connection management for real-time internet applications.

While the underlying protocol has been developed from scratch, Redpine has an event-driven API based on the venerable ENet, and was written based on lessons learned during the development of its predecessor, UFlow. In particular, Redpine makes four key improvements to UFlow:

Event-driven, optionally-blocking implementation

Users no longer need to continually call service(...) to exchange data, and the server never iterates over the list of connected clients. Instead, Redpine generates API events by scheduling timers and automatically waking while blocking on the internal socket. A polling-based call which does not block is still provided.

Simplified congestion control

Instead of a math-heavy TFRC implementation, a lightweight congestion avoidance algorithm that mirrors TCP Reno is used. This and the previous point should increase the number of simultaneous connections that a server can handle, and will likely improve TCP-friendliness overall. An algorithm based on TCP CUBIC will be considered in the future.

Simplified packet streaming model

Redpine does away with having many virtual packet channels that each support a mixture of send modes. Instead, packet fragments are sent in a round-robin fashion from one of two send queues: a queue containing reliable packet data, and another containing unreliable packet data. For packets in the unreliable queue, the user specifies how long a packet has before it expires.

It is thought that this model is sufficient for the majority of real-time internet applications. However, channel-oriented methods for mitigating head-of-line blocking in the reliable queue are still under consideration. (Frankly, I couldn't come up with a use case that rationalized the complexity of the previous sequencing model, considering some amount of application-level reordering will always be required.)

4-way, SipHash-validated handshake

When a server receives an initial handshake from a client, the server does not allocate any resources, but instead replies with the data it would have saved, signed with a SipHash MAC. The connection will be established once the client repeats this data + MAC, proving to the server that a previous handshake frame was sent, and that the client is at the address that it claims to be. By preventing address spoofing this way, Redpine is much more resilient to DDoS attacks.

TODO

• Account for IPv6 header size in MTU

• Expose configuration for MTU

• Figure out data-limited congestion-avoidance

• Add overview to documentation