Switch to quinn
alecmocatta opened this issue · 2 comments
The current implementation using the berkley socket API for TCP is a nightmare, primarily due to it being difficult to a) shut down TCP neatly and b) recover from transient "errors" that reset connections.
Fortunately quinn
doesn't have these issues and is great to work with.
This will involve one big API change: Sender::new
and Receiver::new
will be replaced by let (sender, receiver) = channel();
, which mirrors futures::channel::mpsc::channel()
. Sender
s and Receiver
s will be (de)serializable. This will also ensure static type safety 🎉
Hi @alecmocatta, just by curiosity, why quinn
and not quiche ?
@harksin quinn
integrates with std::future::Future
and tokio
, whereas quiche
necessitates an explicit event loop (probably mio
). I value the former paradigm more. I got the sense that quinn
is more ambitious and more ambitious in leveraging the Rust language and ecosystem, whereas quiche
is more focused on encapsulated C/C++ bindings. Overall I really liked the design and implementation of quinn
, whereas quiche
didn't excite me as much.