search

snapview / tokio-tungstenite

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

Is it possible to read the message to something implement `AsyncRead` trait? #219

Closed hronro closed 2 years ago

hronro commented 2 years ago

Currently all messages are read as Message enum, which means we have to wait the whole message getting received.

I wonder if a message can be read as something implement tokio::io::AsyncRead trait, so we can start process the message after receiving the first byte of the message.

daniel-abramov commented 2 years ago

Currently, it's not possible and we have not planned to implement it as it would essentially mean that we remove the WebSocket abstraction layer and turn WebSocket into a "plain TCP" (e.g. if someone reads the messages byte-by-byte without really separating them on messages, then the WebSockets as the protocol does not make much of a sense, since in such cases the users can rely on a regular TCP instead).

hronro commented 2 years ago

I agree for most cases people don't need this. But in some cases for a specific message, if people know this would be a message contains some streaming data, for example the server pushes a video file to the client, the client may want to play the video in time instead of waiting for receiving the whole video file.

Plus, the RFC 6455 allows sending unknown size of data in WebSocket using fragmentation (see https://datatracker.ietf.org/doc/html/rfc6455#section-5.4). However with current implementation of tokio-tungstenite, we are not able to do such of things.

daniel-abramov commented 2 years ago

I agree for most cases people don't need this. But in some cases for a specific message, if people know this would be a message contains some streaming data, for example the server pushes a video file to the client, the client may want to play the video in time instead of waiting for receiving the whole video file.

The problem is that in order to support it on the receiving side we'll have to introduce an API that is different on sender/receiver side and the whole definition of Stream and Sink becomes sort of very complicated for normal use then.

Plus, the RFC 6455 allows sending unknown size of data in WebSocket using fragmentation (see https://datatracker.ietf.org/doc/html/rfc6455#section-5.4). However with current implementation of tokio-tungstenite, we are not able to do such of things.

This thing we do already support 🙂

hronro commented 2 years ago

This thing we do already support 🙂

Sorry didn't notice that 😂