[Libwebsockets] Is a callback guaranteed after calling libwebsocket_callback_on_writable_all_protocol ?

Andy Green andy at warmcat.com
Mon Mar 13 18:06:19 CET 2017

On March 13, 2017 11:33:49 PM GMT+08:00, Simon Schmid <simon at at-point.ch> wrote:
>I wanted to ask whether it is guaranteed that every connected client on
>websocket server will get a callback in the next `lws_service` call
>when I
>issue a `libwebsocket_callback_on_writable_all_protocol`

No, it's absolutely not guaranteed.

Each connection will get the write-able callback at the time when it is next able to be written to.  For idle connections, or high bandwidth connections, that will usually be the next service call.  For slow or interrupted connections (guy on LTE goes in a tunnel) it will be when and if communication with him starts moving again. 

>In my case I have a ringbuffer which gets filled in a non-blocking
>i.e oldest data is overwritten when full and I keep the current tail
>position for every client in their session data. This makes it
>necessary to
>adjust the tail pointer of some clients in case of an overflow.

Yeah... this is the same way as the mirror example protocol.

>Another option would be to enumerate all connected clients and adjust
>tail pointers as I insert into the ring buffer. But I haven't found a
>to enumerate all connected clients, is there one?

The ...all_protocol() type apis effectively do this.

Otherwise you don't need it... at the time the connection becomes writable, you know that connection's last written tail, if you maintain a counter instead of a pointer the MSBs of it will know how many samples missed from FIFO overflow in the interim and you can deal with skipping forward for that individual connection.

The main point is the reality your side is not in control of when a remote peer can take more data, it's up to him and the network conditions between you.  The amount of delay between asking for the writable callback and getting it for each connection encapsulates this individually for each connection.  The ringbuffer and the skipping forward concept you have are the right partners for that.


>The whole application is single threaded, and LWS gets to service the
>socket every 50ms.

More information about the Libwebsockets mailing list