[Libwebsockets] Forced disconnect for chocked connections

Andy Green andy at warmcat.com
Wed May 18 13:41:48 CEST 2016



On 05/18/2016 07:20 PM, Andrejs Hanins wrote:
> Andy,
>
> On 05/18/2016 12:48 PM, Andy Green wrote:
>>
>>
>> On 05/18/2016 05:37 PM, Andrejs Hanins wrote:
>>> Hi,
>>>
>>> As per documentation, one needs to enable TCP keep-alive to be
>>> able to deal with chocked connection (not writable sockets), but
>>> in my design there is a higher level timeouts which may request
>>> to close a WS connection. Those close requests don't come from
>>> the LWS callbacks, so I can't directly return -1 to LWS and need
>>> to request writable callback which will never come if the
>>> connection is chocked.
>>
>> Hum I think in other words it's suggesting "close from another
>> thread" which can't fly.  But I do see the point.
> No no. I have glib-based main loop and everything works in one
> thread. So I want to close a WS connection from the same thread, but
> not from the LWS callback. In my case this is asynchronous glib-timer
> callback.

How about just set a -1s timeout on the wsi then?

>>> I'm thinking about some new API which will give a way to close a
>>> socket from outside of the LWS callbacks despite any chocked
>>> state.
>>>
>>> Andy, others, do you think it could be a valuable improvement? I
>>> don't really like that TCP keep-alive is the only way to deal
>>> with chocked connections, especially when there are other higher
>>> level timeouts implemented in use code.
>>
>> Yes I do think there's something to add here.
>>
>> But maybe it's about adding auto-PING/PONG timeouts on idle
>> connections.  There's no point sending PINGs on active connections
>> since to stay active, he has to be getting the remote ACKs.
>>
>> If a connection remains choked for a long time, in other words no
>> TCP ACKs are coming, which implies no traffic is passing or the guy
>> consuming the data is deadlocked, either way it's necessary he
>> should be forcibly closed from the server side after a while.
>>
>> Lws timeouts (synchronously, within the service thread framework)
>> can do the business end of that OK.
>>
>> Maybe what's needed is associate "send a ws PING if this connection
>> has been idle for n sec" and "set an lws timeout when you send the
>> PING" that is cleared by the PONG receipt.
>>
>> Because there are many "invisible" ills that might befall the
>> remote peer or its interconnection that can't otherwise be
>> determined.
>>
>> Will this solve your problem?
> Well, auto-pinger in LWS would solve the problem with chocked
> connections (my higher level code does exactly that - sends WS
> PINGs), but it will not solve a more generic case when user code just
> wants to unconditionally and immediately close the connection from
> the same thread but not from the LWS callback. This might not be
> related to timeouts at all.

Still the auto PING is a missing piece (as proven by the fact you had to 
implement it on top of lws)

-Andy

>> -Andy
>>
>>> BR, Andrey _______________________________________________
>>> Libwebsockets mailing list Libwebsockets at ml.libwebsockets.org
>>> http://libwebsockets.org/mailman/listinfo/libwebsockets
>>>
>



More information about the Libwebsockets mailing list