snapview / tokio-tungstenite

Future-based Tungstenite for Tokio. Lightweight stream-based WebSocket implementation
MIT License
1.88k stars 236 forks source link

Is there is a way to use a "raw" WebSocket like `tungstenite::protocol::WebSocket::from_raw_socket`? #238

Closed stackinspector closed 2 years ago

stackinspector commented 2 years ago

Sometimes it is convenient to use WebSocket as a "dumb" protocol on top of TCP, to avoid some of the underlying TCP details. In this case, the canonical HTTP handshake can be omitted. Using tungstenite directly can do this by converting TcpStream with WebSocket::from_raw_socket. But when I want TLS connections and asynchronous processing, I found that this crate doesn't expose a method like from_raw_socket. Consider implementing a similar method in this crate? If not, it seems necessary for me to create a new crate to encapsulate the "raw" WebSocket specifically. BTW consider adding a feature to the handshake related parts of crate tungstenite to support removing them in the complied product? (I know maybe I'm already asking a bit too much)

daniel-abramov commented 2 years ago

tokio-tungstenite does expose a similar method though ;)

BTW consider adding a feature to the handshake related parts of crate tungstenite to support removing them in the complied product? (I know maybe I'm already asking a bit too much)

If I'm understanding it correctly, you mean extracting the basic WebSocket functionality outside of the crate (and/or making it available in a separate loosely coupled module in tungstenite), so that other crates could rely on it? If that's what you meant, then I agree that it would be useful. In fact, we had some internal discussions with @jxs that it would be indeed not that bad to have some sort of a tungstenite-core that provides stream-agnostic API to deal with WebSockets. That would also be very beneficial for tokio-tungstenite, since currently we have a kludge for the requirement of tungstenite of Stream be Read + Write (which Tokio's AsyncRead + AsyncWrite are not directly compatible with).

stackinspector commented 2 years ago

Sorry for not carefully checking the API indeed. The provided API fits my demand perfectly. Looking forward to seeing tungstenite-core which will reduce a bunch of dependencies.

stackinspector commented 2 years ago

I wrote a simple "headless" ws/wss client/server library based on tokio-tungstenite and tokio-rustls, and this is what I actually need. I think it would be better if the handshake related code could be turned off with a feature. For example, for tokio-tungstenite just including WebSocketStream and tungstenite re-export, and for tungstenite not including the handshake, client, server mods.

daniel-abramov commented 2 years ago

Oh, right, there is already a feature that allows to not import any handshake-related types that were recently added to tungstenite, and there is an open request for tokio-tungstenite here: https://github.com/snapview/tokio-tungstenite/pull/240

I think we'll just need to merge it and release both crates with the new feature.

stackinspector commented 2 years ago

When is the next version of this crate planned to be released?

daniel-abramov commented 2 years ago

Theoretically, we could bump a version and release a crate if someone is in need of the introduced feature (we don't have a strict release cycle, we release as soon as there are some good changes/features that are worth being released 🙂).

stackinspector commented 2 years ago

So do you think optional handshake worth?

daniel-abramov commented 2 years ago

We could release it, yeah, why not.