[Libwebsockets] browser flow-control

Per Bothner per at bothner.com
Sun Mar 12 22:11:13 CET 2017

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 timer.

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:
After processing a message of N bytes, the browser does:
   bytesProcessed += N;
   if (bytesProcessed > bytesReported + 500) {
       bytesReported = bytesProcessed;

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)

(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 to
send a handshake for every short message.

Do you see any flaws with this protocol?
	--Per Bothner
per at bothner.com   http://per.bothner.com/

More information about the Libwebsockets mailing list