[Libwebsockets] Acknowledgement on lws_write / LWS_WRITE_BINARY?

[Andy Green]

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.

-Andy

> 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