Question about usrsctp_sendv() error codes EWOULDBLOCK and EAGAIN with non blocking sockets

[jmillan]

Hi,

We're sometimes getting such error codes (not sure which one of them, since we handle both under the same condition) upon calling usrsctp_sendv. We are using non blocking sockets.

Up to now we are considering that such errors indicate that the send buffer is full. We are setting the send buffer size and also controlling that we are not calling usrsctp_sendv() if there is no enough free send buffer.

Is there any other reason these return codes?

This is how we set the send buffer size:

usrsctp_setsockopt(this->socket, SOL_SOCKET, SO_SNDBUF, &bufferSize, sizeof(int))

Thanks.

[tuexen]

No, that is basically the reason. Setting the send buffer size also looks correct.

[jmillan]

Thanks, then we are basically not calculating properly (from outside usrsctp) the remaining free send buffer of a socket. If there was a way to know the remaining free buffer before calling usrsctp_sendv please, I'd be glad to know about it.

We are buffering sending data in higher layers of the app, trying to calculate when there's enough free send buffer in usrsctp, and when it's time, sending out the data using usrsctp_sendv.

[tuexen]

SCTP also takes some overhead into account... Would using the send_cb an option for you? It gets called when a certain amount of free space in the send socket buffer is available...

[jmillan]

SCTP also takes some overhead into account..

This may very well respond to the current behaviour. Is that overhead amount something known, or is there a safe percentage of the total configured send buffer we could consider as overhead so we can properly and safely deduce the free usable send buffer amount?

Would using the send_cb an option for you?

Yes, we already do. We use it to calculate the current free buffer.

[tuexen]

SCTP also takes some overhead into account..

This may very well respond to the current behaviour. Is that overhead amount something known, or is there a safe percentage of the total configured send buffer we could consider as overhead so we can properly and safely deduce the free usable send buffer amount?

No, it is not a specific proportion, but depends on how user messages are broken up in chunks.

Any reason why you need the space in the send socket buffer precisely?

Would using the send_cb an option for you?

Yes, we already do. We use it to calculate the current free buffer.

[jmillan]

Any reason why you need the space in the send socket buffer precisely?

We want to know when send buffer in usrsctp, in the most generic sense of send buffer, is full so we buffer data at application level until there is enough space in usrsctp to send it. The primary target is not to loose any application data.

We look at send socket buffer because that's what we can control in usrsctp. We set it to a certain value and then use the send_cb in order to know the send buffer availability. But it is not 100% accurate because as you pointed, there is some overhead used internally.

[tuexen]

So what you describe is exactly the use case of the send_cb. Start sending until the you get and error indiction EWOULDBLOCK or EAGAIN. Then wait until the send_cb fires and send again until you get an error indication. Doesn't that work?

[jmillan]

We do very similarly but I was not 100% sure that after EWOULDBLOCK or EGAIN error, send_cb would always fire.

I'll test this and come back with a confirmation in the following days.

[tuexen]

It should work, if not, it is a bug and I would like to know and fix it.

[jmillan]

Closing the issue. We have made the corresponding modification in order to adhere to this comment.

It's working as expected so far.

Thanks for the help @tuexen.