QUIC
transport research & planning
#353
Labels
experiment
Exploratory design and testing
help wanted
Extra attention is needed
IPC and transport
question
Further information is requested
As a breakout from #136, I'm dumping some recent research links around
the possibility of supporting
QUIC
as being our desired transport inthe longer run instead of
TCP
🏄Seeing as most of the recent implementations are being written in
rust
, seems like this potential work will likely go in tandem with#352 😎
Verbatim content from #136 bullet:
QUIC quick history and high level
info:
latency TCP replacement and it's being slowly standardized and
introduced to http infra on the internet.
connections since with
trio
we can definitely stick to theone-task-per-stream pattern easily.
performance benefits to use cloudfare's rust impl
quiche
on how we might do the python-rust integration
aioquic
hasasyncio
supportusing protocols, so we'll need to figure an alt to that for
trio
.hypercorn
's internal protocol supporttrio
supported udp serverRecent updates on FOSS support:
quinn
: an async quic impl inrust
: https://github.com/quinn-rs/quinnhigh level breakdown of lang support in (impls) of
libp2p
rust-libp2p
last year seemingly basedon the impl in
quinn
(above):quinn-proto
libp2p/rust-libp2p#2289quinn-proto
libp2p/rust-libp2p#2289 (comment)aioquic
asyncio support: https://github.com/aiortc/aioquic/tree/main/src/aioquic/asyncioquicssh
GH project: https://github.com/moul/quicsshberty
messenger: https://berty.tech/docs/protocol/#direct-transportStandards and application compatibility research:
The text was updated successfully, but these errors were encountered: