Slow client can cause send queue to grow indefinetly

[tkarls]

I have experienced that there is no built in handling in websocketpp to cope with the situation that the client is too slow to process messages sent from the websocketpp server.

I have an application that generates quite a lot of real-time statistics and noticed that when some clients were connected the memory consumption would go through the roof (like +1 gig in 30 minutes) due to the fact that m_send_queue in websocketpp\impl\connection_impl.hpp would grow and grow.

I have now built a protection in my app by checking the buffer size using get_buffered_amount() and if too big I disconnect the client.

However, I think some form of flow control should be built into the library. Like zmq's high watermark or some other mechanism.

What do you think?

[zaphoyd]

Basic flow control tools for reading are present already (connection::pause_reading and connection::resume_reading). For writing, presently only the poll-able get_buffered_amount(). This helps in the sense that you can ask, before you send, if buffering is getting out of control. There is presently no good way to get alerted when the buffer is back below a certain threshold without continuously polling. That issue I definitely intend to fix. Specifically, with a handler for when a network write brings the buffered amount below the specified threshold.

I had not specifically considered a high watermark (presumably a handler that would fire when the buffer got above a certain threshold), but it wouldn't be too difficult to add at the same time and would make the API a little cleaner (no need to explicitly poll with every send).

[tkarls]

Thanks for your quick reply.

Yes I noticed the flow control mechanism for reading while digging through the sources and felt that the writing side were a little left out

A handler that fires when a high watermark is hit and another one when the buffer again is below a specific level sounds good to me 😄

[IoanCosminSzanto]

Hi,

I would like to fix this issue by setting a handler which will be fired when the send queue becomes empty.
Would you agree with this solution to go upstream?

[zaphoyd]

I'd accept a PR for a hander that fires when the send queue drops below a particular value.