[Libwebsockets] Fwd: Is a callback guaranteed after calling libwebsocket_callback_on_writable_all_protocol ?

Simon Schmid simon at at-point.ch
Mon Mar 13 22:58:49 CET 2017


2017-03-13 18:06 GMT+01:00 Andy Green <andy at warmcat.com>:
>
>
> Yeah... this is the same way as the mirror example protocol.
>

Yep... the mirror protocol comes very close to what I need.

> >Another option would be to enumerate all connected clients and adjust
> >the
> >tail pointers as I insert into the ring buffer. But I haven't found a
> >way
> >to enumerate all connected clients, is there one?
>
> The ...all_protocol() type apis effectively do this.
>

I just checked `lws_callback_all_protocol` function, but it also says
"When: when the individual connection becomes writeable" in the
documentation, which means it's also not guaranteed I get a callback in the
next service?

> 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.
>

This assumes the ringbuffer has not cycled through completely, i.e the
number of missed entries is less than the ringbuffer's capacity. Let's
assume the client was in a tunnel and gets writeable again after the
producer has written as many elements as the ringbuffer's capacity. In the
callback it now looks like the client is up-to-date and we send him the
newest entry, although it would have been more optimal to choose the oldest
entry.

An absolute counter which increases monotonically could solve this
partially because it can measure the number of missed entries over many
laps. When we get the callback and the number of missed entries is larger
than the ringbuffers capacity, we know the optimal position to start
reading is the oldest entry. However this introduces another issue when the
counter itself wraps around, after 2^32 or 2^64 counts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20170313/2d9b83b3/attachment-0002.html>


More information about the Libwebsockets mailing list