message-io
base-drafts
message-io | base-drafts | |
---|---|---|
15 | 9 | |
1,036 | 1,610 | |
- | 0.1% | |
5.8 | 0.0 | |
3 months ago | 12 days ago | |
Rust | Shell | |
Apache License 2.0 | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
message-io
-
Looking for help deciding which library to use for networking
message-io: a networking library meant to be very simple, built on mio.
-
Crate to build network packets over UDP
Another one I know about, but have not looked into yet, is message-io.
- Is there a proper websockets server framework in Rust?
-
Netty-rs - small rust library to easily write server/client networking protocols at application level
I'm working in a transport network library that possible fits as a building block for yours and solves the problem of using different underlying transports: message-io
-
Announcing message-io 0.12 - an event-driven message library to build network applications easy and fast. Now with zero-copy write/read messages. Performance close to using native OS socket with all the facilities the library offers.
Here is benchmarks
-
Someone built a chat backend with Rust for a production website?
I think https://github.com/lemunozm/message-io can be a good candidate.
-
message-io: an event-driven message library to build network applications easy and fast. Now with WebSocket support
The idea behind message-io is not to populate a current transport with a lot of options/profiles/modifications... this obfuscates the default way of working with it. Instead, if you want to build some behaviour on top of it, it is as easy as making an adapter! Following this pattern, you can split the way of using the library from the behaviour of the transport, keeping the things simple.
-
termchat: Terminal chat application on LAN with file transfer and ASCII webcam video streaming support. Built on top of tui-rs and message-io crates
The initial purpose was to show the capabilities of https://github.com/lemunozm/message-io Nevertheless, Termchat is growing and needs to polish some of its features. At this point it is not for real-world use but I hope to reach this target.
base-drafts
-
Multipath TCP for Linux
QUIC is a step backwards here; it has no multipath support: https://lwn.net/Articles/964377/
Multipath: There are several areas where TCP still has an advantage over QUIC. One of those is multipath support. Multipath TCP connections can send data on different network paths simultaneously — for example, sending via both WiFi and cellular data — to provide better throughput than either path permits individually.
Server connection migration is explicitly forbidden by QUIC:
https://github.com/quicwg/base-drafts/pull/2031
- What does TCP/IP, OSI model even in means in job requirements
-
RFC 9114 – HTTP/3
https://github.com/quicwg/base-drafts/issues/253
TL;DR just like HTTP/2, we wanted to avoid friction in deploying these protocols. Having to rewrite URLs because of new schemes is pretty unpalatable, it has major impact. Instead, HTTP/3 can rely on other IETF-defined mechanisms like Alt-Svc (RFC 7838) and the more recent SVCB / HTTPS RR [1] DNS-based methods. The latter has been deployed on Cloudflare a while [2] and supported in Firefox. Other user agents have also expressed interest or intent to support it.
The net outcome is that developers can by and large focus on HTTP semantics, and let something a little further down the stack worry more about versions. Sometime devs will need to peek into that area, but not the majority.
[1] - https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-...
-
Announcing s2n-quic 1.0
After lots of hard work, we're excited to open-source [s2n-quic](https://github.com/aws/s2n-quic), a Rust implementation of the [IETF QUIC protocol](https://quicwg.org/). Feel free to ask any questions here in the comments or by [opening an issue](https://github.com/aws/s2n-quic/issues/new/choose). Thanks!
- The IETF QUIC Working Group
-
Crate to build network packets over UDP
Maybe check out laminar and quinn, which implement custom protocols on top of UDP (quinn implements QUIC), to get an idea on how to do things.
-
QUIC is now RFC 9000
IETF work is conducted mostly on email lists, hence the "many thousands of emails".
For some newer work like QUIC, GitHub is used to maintain a more to-the-minute shared view of the documents, and then again as mentioned in the text you quoted, GitHub Issues and PRs are used to manage the document, particularly by the most active participants.
https://github.com/quicwg/base-drafts - of course raising issues or PRs for them now won't do anything useful for you, because these RFCs were published. But you can see there were thousands of commits, one of the last being Martin Thompson's minor typographical tweaks summarised as "DOES IT NEVER END?!?".
- QUIC and HTTP/3 Support Now in Firefox Nightly and Beta
What are some alternatives?
MIO - Metal I/O library for Rust.
s2n-quic - An implementation of the IETF QUIC protocol
Netty - Netty project - an event-driven asynchronous network application framework
shadowsocks-rust - A Rust port of shadowsocks
tungstenite-rs - Lightweight stream-based WebSocket implementation for Rust.
quinn - Async-friendly QUIC implementation in Rust
laminar - A simple semi-reliable UDP protocol for multiplayer games
aiortc - WebRTC and ORTC implementation for Python using asyncio
tokio - A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
quicly - A modular QUIC stack designed primarily for H2O
criterion.rs - Statistics-driven benchmarking library for Rust
quiche - 🥧 Savoury implementation of the QUIC transport protocol and HTTP/3