[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:
   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 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