Outgoing message fragmentation

[zaphoyd]

This issue refers to fragmenting "fixed size fully buffered" messages. See issue #35 for work and discussion on unknown size partially buffered outgoing fragmentation.

WS++ as of 0.2 does not fragment outgoing messages. This is desirable for a number of reasons. In particular it improves control message latency times and would be very helpful for wsperf to be able to measure implementation's fragmentation processing overhead. It has some downsides and complications that need to be understood and documented appropriately. In particular:

• What should the interface for fragmenting outgoing messages look like? Fragment message into n pieces? fragment message into pieces of size n bytes?
• Can fragmented messages take advantage of prepared/deduplicated message processing?
• What endpoint and connection options are needed? max fragment size... fragment any message larger than this?

Please use this issue to discuss needs for and questions related to fixed size fully buffered outgoing fragmentation.

[megabyte1024]

You wrote about "fragments" and not about "frames". Are these terms are equal and the future code will send a single frame in one async_write call? or one frame will be sliced to a few fragments?

What should the interface for fragmenting outgoing messages look like? Fragment message into n pieces? fragment message into pieces of size n bytes?

For me, it would be nice to have possibility to set a frame size in bytes.

Can fragmented messages take advantage of prepared/deduplicated message processing?

I am sorry. This question is not clear for me. Could you please to explain it for dummies. :)

What endpoint and connection options are needed? max fragment size... fragment any message larger than this?

For me, the max frame size is important.

As I already wrote, I requested this feature to have timeouts. I think it will be very nice to implement timeouts to send multi-frame messages and receive such messages.

[zaphoyd]

Some terms from the web socket RFC. Message = message delivered via on_message to WS++ or W3C JS API. In WS++ now send() sends a message.

Message payloads are sent in one or more frames. A fragmented message is a single logical message sent in multiple consecutive frames. The payloads of each frame (fragments of the original message) are buffered until the final frame is received and then on_message is called with the full message.

WS++ is capable of receiving multi-frame messages but is not capable of sending them at this time. All outgoing messages are currently a single frame. The proposed change for this issue would be to implement an interface for requesting that WS++ send fragmented messages (one logical message sent via multiple frames).

Regarding prepared/deduplicated message processing. In order to send a message WS++ must wrap it in a frame and perform some processing (masking, utf8 validation, etc). If you send the same message out on multiple connections (as used in pubsub, broadcast, and other common WebSocket use cases) WS++ will only process the outgoing message once and will only store one copy of it. When you have 100k clients connected this drastically improves performance and memory usage.

Making this outgoing message de-duplication work with fragmented messages will at best be tricky and at worse not be possible. The exact state of this situation needs to be determined and appropriate documentation written.

Can you go into some more detail on these timeouts? A 10 byte message sent in 1 byte fragments would result in 10 frames being generated and sent. One async_write per frame. Are you interested in a timeout to allow closing the connection if it looks like the message will take too long to send?

[megabyte1024]

Everything is clear about frames/fragments. Also it is clear about the prepared/deduplicated message processing. I have not opinion on this issue. For me it is not very critical because my application has not thousands of connections. Explaining about timeouts in the next post.

[megabyte1024]

Are you interested in a timeout to allow closing the connection if it looks like the message will take too long to send?

Exactly. My application sends/receives different data types via a single connection. The data can have sizes starting from a dozen bytes and ending with tens of megabytes. Now I specify a timeout for a hypothetical maximal message transmission time, for instance, 10 min, but for small messages, it is not reasonable to wait 10 mins till the connection will be closed. That is why it would be nice to have timeouts for a single frame sending and receiving, i.e. if both both sending and receiving sides have timeouts.

[GradyLee]

@zaphoyd
I have issue that my client receive close frame with code 1009 after sending a big message to server.
Because there is a max frame limit enforced by my server. So the close reason is max frame length of 65536 on server side has been exceeded. It means my client must support splitting large messages into the smaller frames starting from certain size.
I want to ask if websocketpp 0.8.2 support splitting outgoing message into fragments?Do we have some interface to set the max frame size?