How do you signal that you could not consume all available bytes to read ?

[nojb]

Hi I am trying to write bindings for this library exposing a classical BSD-style socket interface (by doing some buffering in between). I have some questions about the semantics of the on_read callback and the get_read_buffer_size callback.

• AFAICS, the on_read callback is called each time there is available data on the socket. Is there any way to signal that the data passed to the on_read callback has not been completely consumed by the upper layer, or should one always make a copy when it is not consumed right away ?
• When is the get_read_buffer_size callback supposed to return ?
• When should one call the function utp_read_drained ?

Thanks!

[anacrolix]

I'm having the same issue. I've written a Go wrapper, and store reads in a buffer, and call utp_read_drained when that buffer is emptied. However I must called utp_issue_deferred_acks to after processing the UDP packets, which has the effect of allowing yet more data to be read. The buffers end up very large.

[arvidn]

there is no way to indicate that payload received by on_read has not been consumed by the upper layer. If you cannot consume it immediately, you need to stick it in a buffer, similar to how the kernel buffers payload received over TCP. It sits in the buffer until the upper layer has consumed it with a read() call. If you're providing BSD semantics, you need to provide that buffer.

as for the get_read_buffer_size callback; it will be called periodically by libutp to adjust its advertised receive window to the other endpoint. You are supposed to return the number of bytes you have buffered, that the upper layer has not yet consumed. In your case, you should return the number of bytes, received by on_read but not consumed by. i.e. the size of your receive buffer for this socket.

The utp_read_drained call should be called when the underlying UDP socket return EAGAIN. i.e. you have drained the underlying socket of packets. This is used to defer sending ACKs until a whole packet train has been consumed. This improves performance and bandwidth usage.

Please consider submitting a PR with improvements to the documentation!

[anacrolix]

Thanks @arvidn , I'll see if implementing the get_read_buffer_size callback makes an improvement.

[anacrolix]

I believe it did. It was a while ago.