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: