Advantages / Motivation about tokio-tungstenite HOT 2 CLOSED

As for motivation for creating tungstenite-rs I can say that there was no other websocket crate which could satisfy our needs back then. As far as I can remember, when I checked the crates.io for websocket support I was able to find only rust-websockets and ws-rs. rust-websockets was not considered stable and there were many warnings that the library should not be ready for production use etc, in overall there were many pending issues and no support for async/tokio architectures (the code required a major refactoring and autobahn test suite did not gave the best results). Also the last commits to the library were made a year ago when I checked it, so the library seemed to be abandoned and we did not consider it for production use. ws-rs on the other side seemed to be production-ready, that was the only solution which worked fine and provided a convenient API, however later we found several major limitations which were essential to us:

• Security issues with TLS, which had to be fixed by @agalakhov in one of the pull request (can be found in issues history).
• An architectural problems, which made it impossible to run ws-rs with tokio or split the processing of incoming websocket connections into separate threads. These issues are still open, one of them is: housleyjk/ws-rs#70

Generally speaking there were many things we wanted to improve in ws-rs and which required a big refactoring, as a result of this refactoring tungstenite-rs came to life. tungstenite-rs just provides a simple, small yet powerful and fast library which allows you to deal with websockets, it does not force you to use tokio or mio or any other layer of abstractions, it just provides you all tools (websocket handshake, message handling) to have websocket support. You can use it right away in a blocking mode with a standard TcpStream or you can implement some mio-based (event-based) logic like ws-rs does or tokio-based wrapper around it (tokio-tungstenite is just our first try to implement tokio-based wrapper around tungstenite-rs, as you can see tokio-tungstenite is very small, simple and well-documented, it's already suitable for production use as well as tungstenite-rs and works fine, although we still think how to improve several things there, we may change the API for it when we find a better model than we have it now).

As for tk-http, it did not exist back then.

To sum up. If we compare tungstenite-rs and tokio-tungstenite to ws-rs, I would say that the major advantages are:

• tungstenite-rs is much more flexible, you can build anything you want on top of it, or you can use it as is, or... you can use our tokio version of it (tokio-tungstenite). tungstenite-rs itself does not limit you in the way you organize reading from stream or backpressure, you can use it with any stream/buffer which implements Read + Write.
• As far as we know (it was also once mentioned by ws-rs author), tungstenite is faster than ws-rs (housleyjk/ws-rs#74 (comment)). We also made several low level optimizations since then, so it has to be faster.
• Currently it also passes autobahn tests better than ws-rs does.

I cannot make an objective comparison to websocket crate, as websocket changed a lot since I checked it last time. One year ago it was much slower than ws-rs (comparison at https://ws-rs.org/) and as we're faster than ws-rs, I can assume that we're also faster than websocket :) But honestly -- I don't know. I have to check the websocket crate again, they added support for many things and so several things have to be re-measured again. The links from the website still point to some invalid URLs which do not exist anymore (and there is still a warning that the library is not suitable for production use).

I had a short look at tk-http, the biggest difference is that they're tokio-based, so it's not as flexible as tungstenite-rs in this aspect, although it provides many interesting ways to deal with websockets, they have quite a different architecture I would say (at least based on the documentation), so their API is a bit different from ours. However, the one can easily implement the same API on top of the existing tungstenite-rs, i.e. "tk-tungstenite" can be built on top of tungstenite-rs.

from tokio-tungstenite.

wow, thanks for that long explanation!!

I'm curios if there will be some efforts to combine the power of several crates to not reinvent the wheel over and over again. tungstenite-rs seems to be a good foundation others could build on :)

from tokio-tungstenite.