[Libwebsockets] browser flow-control

Andy Green andy at warmcat.com
Sun Mar 12 21:55:02 CET 2017



On March 13, 2017 4:30:45 AM GMT+08:00, Per Bothner <per at bothner.com> wrote:
>On 03/12/2017 01:18 PM, Andy Green wrote:
>
>>> But what if the file is infinite? I.e. it's printing in an endless
>>> loop?
>>> I could tolerate this too, as long as the user can type ctrl-C, and
>>> that
>>> is handled and gets sent to the looping process, and kills that
>>> process.
>>> But the ctrl-C isn't getting through - I'm not sure why, but I
>suspect
>>> it's just a scheduler in the browser that isn't designed to handle
>>> these situations.
>>
>> This is true in both, eg, ffox and chrome?
>
>Yes.  Chrome is better, in that an infinite-looping DomTerm display
>doesn't freeze
>the entire browser - just the DomTerm tab/window.  But each window is
>still only
>going to be one process, as JavaScript itself is single-threaded.

Nasty.... it sounds like while there's a pending onMessage() you're stuck.

If that's really it, the only way to solve it is not have an onMessage() pending some of the time... and the only way to do that is the sender stops sending at intervals.

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.

-Andy



More information about the Libwebsockets mailing list