You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not really. I am referring to the section 5.4 of the RFC-6455.
The primary purpose of fragmentation is to allow sending a message that is of unknown size when the message is started without having to buffer that message. If messages couldn't be fragmented, then an endpoint would have to buffer the entire message so its length could be counted before the first byte is sent. With fragmentation, a server or intermediary may choose a reasonable size buffer and, when the buffer is full, write a fragment to the network.
A secondary use-case for fragmentation is for multiplexing, where it is not desirable for a large message on one logical channel to monopolize the output channel, so the multiplexing needs to be free.
This issue relates to the client not being able to receive fragmented messages sent by the server.
If you look at the example I provided above you will see the effect of this on a client using WebSocket4Net to connect to a server sending fragmented messages. It essentially never receives such messages.
First of all, your library is great! so thank you for making it available.
It will be very useful if WebSocket4Net could support fragmentation.
As far as I am aware, both Microsoft's
ClientWebSocket
and WebSocketSharp support fragmentation but based on my last test WebSocket4Net does not.Thank you,
Nima
The text was updated successfully, but these errors were encountered: