[Libwebsockets] Acknowledgement on lws_write / LWS_WRITE_BINARY?

Duane Butler Duane.Butler at calix.com
Mon Sep 14 21:15:28 CEST 2020

Thanks, Andy.

-----Original Message-----
From: Andy Green <andy at warmcat.com> 
Sent: Saturday, September 12, 2020 2:07 PM
To: Duane Butler <Duane.Butler at calix.com>
Cc: libwebsockets at ml.libwebsockets.org
Subject: Re: [Libwebsockets] Acknowledgement on lws_write / LWS_WRITE_BINARY?

[External Email]

On 9/12/20 6:15 PM, Duane Butler wrote:
> Andy, another quick question. Is it generally true that the transport is reliable? I’ve always assumed so since it is based on a TCP connection.

Yes tcp is "reliable", but what does it really mean?

If you pull out the ethernet cable on the sending side, and you are sending small packets on an established tcp connection, the kernel will continue to accept the packets for many minutes before it starts to feel something is wrong.

So tcp is "reliable", but from the perspective of a POSIX socket sending, everything is fine even with no ethernet cable in.  POSIX doesn't reveal how long the packet has gone without an ACK, so the userland app can't assess this for itself.  Having "sent" it without error on a "reliable" transport, it has to take it on faith it actually went out, even with no cable in.

Similarly, the peer may receive and ack the packet at tcp level, but...
what does it really mean?  Does it mean the app is there and alive and it updated and committed to the database backing store according to what your packet told, or your database is up or the ssd is not in flames?

There are other corner cases where, eg, local wlan router is up and WLAN network interface is linked-up fine, but something downstream is down or brain damaged, or routes on the internet differ for each direction, and either only rx or tx can work but not both.

Yes tcp is "reliable" but it turns out you can't believe anything really happened unless it involves the actual endpoints either having synchronous request-response, or returning a token sent by the originator back to it to prove that it has had that specific message, and from its whole app perspective (ssd still working, database still there etc) what was asked for truly did happen.


> Thanks.
> Duane.
> Sent from my iPhone
>> On Sep 12, 2020, at 11:35 AM, Duane Butler <Duane.Butler at calix.com> wrote:
>> Thanks Andy, that’s kind of what I thought, but wanted to check.
>> Sent from my iPhone
>>> On Sep 12, 2020, at 10:53 AM, Andy Green <andy at warmcat.com> wrote:
>>> [External Email]
>>>> On 9/12/20 4:48 PM, Duane Butler wrote:
>>>> Hello,
>>>> We’re using libwebsockets 4.0 stable.
>>>> We are seeing cases where client LWS_WRITE_BINARY messages are not 
>>>> being delivered due to unstable network connections and websocket 
>>>> closures in the middle of pending writes.
>>>> Is there a way for a client application to know if a message was 
>>>> actually delivered to the other side or not?
>>> ws itself doesn't offer the concept of "transactions" in the same 
>>> way as, eg, http does, with a "request" and then a "response" with 
>>> an explicit code saying the disposition of the request.
>>> If you want that, you have to add it into your ws subprotocol, eg, 
>>> every outgoing ws message with your subprotocol has an incrementing 
>>> ordinal or random token, and the peer will report back with an 
>>> explicit disposition message listing which ones it saw and what the disposition was.
>>> -Andy

More information about the Libwebsockets mailing list