[Libwebsockets] new ws timeout on sleep

Andy Green andy at warmcat.com
Sat Nov 28 11:56:00 CET 2020

On 11/27/20 4:09 PM, Per Bothner wrote:
> On 11/27/20 7:46 AM, Andy Green wrote:
>> If it's actually on I don't know that should actually go 
>> down from userland perspective during suspend... and if it is closed, 
>> it should close immediately.  So maybe this is something else... if 
>> you can try main from October at 
>> 915f888f3e78be3a42e66a627bcc6ce1d679d5d3 just before the netlink role 
>> was added that might give a hint.
> It seems to work ok (with no timeout) using 
> 915f888f3e78be3a42e66a627bcc6ce1d679d5d3.

Thanks... I set up a spare NUC here that can suspend well and ran the 
minimal-ws-client against the libwebsockets-test-server and studied what 
happens on suspend.

Basically the work for RFC6724 is part of another feature at a higher 
level which is still a WIP.  The RFC6724 part was still missing properly 
marking the wsi with which route it was estimated to use, all the 
infrastructure around that was there and the wsi close stuff works, it 
just didn't mark the wsi accordingly.

I added the remaining missing bits on main and that help it understand 
that losing the default route on another network interface (which was 
what happened with the suspend) shouldn't have any impact on connections 
that use a different source address than the interface had whose route 
was unaffected by the suspend.

Hopefully that'll make things act well for connections going out 
externally (which should be cut off by loss of the default route under 
this scheme) and on lo (which should stay up).


More information about the Libwebsockets mailing list