Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative IPC and messaging transports #136

Open
2 tasks
carlosplanchon opened this issue Jul 27, 2020 · 7 comments
Open
2 tasks

Alternative IPC and messaging transports #136

carlosplanchon opened this issue Jul 27, 2020 · 7 comments
Labels
discussion enhancement New feature or request experiment Exploratory design and testing IPC and transport

Comments

@carlosplanchon
Copy link

carlosplanchon commented Jul 27, 2020

Goal: To integrate a UDP based transport protocol in order to
improve resiliency and latency for multi-host IPC use cases.


NOTE LOTS OF EDITS by @goodboy (mostly summarized from below comments).


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




@goodboy
Copy link
Owner

goodboy commented Oct 23, 2020

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:

@goodboy goodboy changed the title RUDP Transport support. Alternative UDP based transport(s) Oct 23, 2020
@goodboy goodboy added discussion enhancement New feature or request experiment Exploratory design and testing labels Oct 23, 2020
@goodboy
Copy link
Owner

goodboy commented Oct 23, 2020

@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
Copy link
Collaborator

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

@goodboy
Copy link
Owner

goodboy commented Nov 27, 2020

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:

@goodboy
Copy link
Owner

goodboy commented Mar 19, 2021

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

@goodboy
Copy link
Owner

goodboy commented Sep 15, 2021

Linking this with python-trio/trio#2047!

@goodboy goodboy changed the title Alternative UDP based transport(s) Alternative IPC and messaging transports Jan 6, 2023
@goodboy
Copy link
Owner

goodboy commented Jan 6, 2023

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 🏄🏼

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion enhancement New feature or request experiment Exploratory design and testing IPC and transport
Projects
None yet
Development

No branches or pull requests

3 participants