[Libwebsockets] browser flow-control

Andy Green andy at warmcat.com
Sun Mar 12 23:00:30 CET 2017

On March 13, 2017 5:11:13 AM GMT+08:00, Per Bothner <per at bothner.com> wrote:
>On 03/12/2017 01:55 PM, Andy Green wrote:
>> There seems no nice way to detect the spamming stopped... the
>protocol could contain a bit that says the sender is halting
>electively.  The onMessage handler could send a resume packet back
>immediately... that should mean no new message came for 2 x Round-Trip
>Times.  Maybe worth a try... if not enough send the resume packet on a
>That's why I was considering:
>Both the server and the browser maintain a count
>of number bytes (or characters) respectively sent and received.
>The browser has these state fields:
>   bytesProcessed
>   bytesReported
>After processing a message of N bytes, the browser does:
>   bytesProcessed += N;
>   if (bytesProcessed > bytesReported + 500) {
>       bytesReported = bytesProcessed;
>       send_ready_for_more_message(bytesReported);
>   }
>The server:
>   int bytesSent
>   int bytesReported
>receive_ready_for_more_message(N) {
>   bytesReported = N;
>   if (client_suspended) wake_up_client();
>send_message(msg) {
>   bytesSent += msg.length;
>   if (bytesSent > bytesReported + 2000)
>      suspend_client();
>(A minor complication is dealing with counter wrap-around.)
>This lets the sender get 2000 bytes ahead, so you don't have to wait
>for a
>round-trip handshake.  The 500 in the browser code is to avoid having
>send a handshake for every short message.
>Do you see any flaws with this protocol?

You're going to have to try it and see, I at least am very uncertain about the mechanism you're working around.  Maybe it's enough to just rate-limit the sending... it may be the browser is happy to eat amounts of network data the JS side chokes on.


More information about the Libwebsockets mailing list