Alt IPC transports: what should be our built-in set?

[carlosplanchon]

NOTE this descr is more-or-less rewritten entirely by @goodboy

---

What "next/old-gen" protos are worth having first class support?

Now that #375 gives us a modular tpt layering it's time to start making those choices

B)

---

Here are the main few protocols which have caught our attention:

• TIPC as per detailed writeup in Investigating TIPC, the "end game" cluster proto maybe? #378

• DTLS, which is soon to get now has native support in trio!

  • docs: https://trio.readthedocs.io/en/stable/reference-io.html#datagram-tls-support
    • https://pypi.org/project/service-identity/
  • feature req: DTLS support python-trio/trio#2010
  • pr: DTLS support python-trio/trio#2047
  • quora on the diffs with QUIC
  • anyio issue for the same

• QUIC

  • developed at google. It's branded as a multiplexed-UDP: a low latency TCP replacement and it's being slowly standardized and introduced to http infra on the internet.
  • the semantics of QoS / cancellation of sub-streams within connections since with trio we can definitely stick to the one-task-per-stream pattern easily.
  • the stack is implemented in user space and thus it may have performance benefits to use cloudfare's rust impl quiche
    • comment notes on how we might do the python-rust integration
  • there is an existing Python sans-io implementation aioquic has asyncio support using protocols, so we'll need to figure an alt to that for trio.
  • Here's a list of uses / example code:
    • hypercorn's internal protocol support
    • an example of their trio supported udp server

• RUDP is a historical approach to this kind of thing but there's been improvements in this space since (see above). Some relevant RUDP resources include:

  • https://tools.ietf.org/id/draft-ietf-sigtran-reliable-udp-00.txt
  • https://github.com/kalasoo/rudp
  • https://github.com/andrewzk/Reliable-UDP/blob/master/rudp.c

---

• UCX a unified foss comms layer with multiple transport support for local and multihost: https://github.com/openucx/ucx#supported-transports
  • github repo
  • python lib is ucx-py
  • install tips for the above at https://github.com/rapidsai/ucx-py

[goodboy]

An interesting protocol I recently started reading about is QUIC developed at google. It's branded as a multiplexed-UDP: a low latency TCP replacement and it's being slowly standardized and introduced to http infra on the internet.

I'm actually pretty interested in the semantics of QoS / cancellation of sub-streams within connections since with trio we can definitely stick to the one-task-per-stream pattern easily.

Python sans-io implementation aioquic has asyncio support using protocols, so we'll need to figure an alt to that for trio.

Here's a list of uses / example code:

• hypercorn's internal protocol support
• an example of their trio supported udp server

[goodboy]

@ryanhiebert it supposedly is sans-io as per:

Both the QUIC and the HTTP/3 APIs follow the "bring your own I/O" pattern, leaving actual I/O operations to the API user. This approach has a number of advantages including making the code testable and allowing integration with different concurrency models.

Maybe I've misunderstood detailed semantics of sans though.

There's an asyncio backend: https://github.com/aiortc/aioquic/tree/main/src/aioquic/asyncio

[ryanhiebert]

That's cool. Weird name for a sans-io package. So I guess we'd have to write the trio backend.

[goodboy]

Some further QUIC resources.

From the wikipedia:

QUIC uses UDP as its basis, which does not include loss recovery. Instead, each QUIC stream is separately flow controlled and lost data retransmitted at the level of QUIC, not UDP. This means that if an error occurs in one stream, like the favicon example above, the protocol stack can continue servicing other streams independently. This can be very useful in improving performance on error-prone links, as in most cases considerable additional data may be received before TCP notices a packet is missing or broken, and all of this data is blocked or even flushed while the error is corrected. In QUIC, this data is free to be processed while the single multiplexed stream is repaired.[19]

In short the protocol is implemented in user space meaning the stack needs to be fast and likely written in a faster language then python. There's a rust implementation quiche we may be able to bind to somewhat fluidly using pyO3. Some further posts from cloudfare:

• https://blog.cloudflare.com/enjoy-a-slice-of-quic-and-rust/
• https://blog.cloudflare.com/http-3-from-root-to-tip/

[goodboy]

Dropping this little project:
https://github.com/lithdew/reliable

[goodboy]

Linking this with python-trio/trio#2047!

[goodboy]

Linking to #109 which includes localhost only options. we should probably break up the set of multi-host vs. local host options for investigation by some eager lurkerz 🏄🏼