<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><span class="">2017-03-13 18:06 GMT+01:00 Andy Green <<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>>:<br>><br>><br>> Yeah... this is the same way as the mirror example protocol.<div>></div><div><br></div></span><div>Yep... the mirror protocol comes very close to what I need.</div><div><span class=""><br>> >Another option would be to enumerate all connected clients and adjust<br>> >the<br>> >tail pointers as I insert into the ring buffer. But I haven't found a<br>> >way<br>> >to enumerate all connected clients, is there one?<br>><br>> The ...all_protocol() type apis effectively do this.<br>><div><br></div></span><div>I just checkedĀ `lws_callback_all_<wbr>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?</div><span class=""><div><br></div><div>> 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.<br>></div><div><br></div></span><div>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.</div><div><br></div><div>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.</div></div></div>
</div><br></div>