Unable to determine if zero-length UDP datagram was sent

[abitofevrything]

• Dart version 3.11.0-90.0.dev
• OS: Linux

When sending datagrams to a RawDatagramSocket, the return value of send is used to determine whether the datagram was sent correctly. It always returns 0 or the length of the sent datagram, with 0 indicating the datagram was not queued for sending by the OS.

This leads to an ambiguity when sending a datagram with length 0: does a return value of 0 mean the datagram was queued for sending, or does it mean the write failed?

The issue stems from _NativeSocket.send returning 0 when an error is thrown instead of returning -1, as linux does for failed writes, for example.

It could be possible to use the associated error sent on the _RawDatagramSocket to determine if the write failed, but this error is only sent in a later microtask so associating it with a specific send call is difficult.

Of course changing the error return value from 0 to -1 would be a breaking change, so maybe we can have some alternative way of checking if the last send call succeeded?

[RohitSaily]

I am completely unfamiliar with this subject so forgive me if this does not help but in the docs it says:

If a local failure to send the datagram occurs then an error event will be added to the Stream

It seems like there is a stream that can be listened to for determining if it was sent or not.

---

I agree that it would be nice to have an alternative API that considers the empty case directly with its return value, keeping things simple.

[abitofevrything]

@RohitSaily yes, an error will be reported on the stream, but using this as a mechanism for determining send failures is brittle, as I explained in the issue itself:

It could be possible to use the associated error sent on the _RawDatagramSocket to determine if the write failed, but this error is only sent in a later microtask so associating it with a specific send call is difficult.

[RohitSaily]

I noticed the API returns synchronously.

If I understand correctly then it synchronously attempts to queue the datagram and that will then be processed asynchronously, if queuing is successful.

In that case, even if the datagram could be identified from the stream, it is not clear that the stream reports the blocking case (ie return 0). So an alternative API may indeed be necessary.

Maybe we can implement effectively the same method but return null for the blocking case? Or would -1 be preferrable for any reasons?

Then we could deprecate the old API.

[abitofevrything]

As the API currently stands, there are only two possible return values: 0 (sending failed) or buffer.length (sending succeeded). So changing the return type to bool would be an option, although breaking. Adding an alternative API and then deprecating the old one also works, but feels a little clunky, so I'm not sure what the best approach would be here.

If sending failed due to an error, that error is added to the stream, though this issue isn't about the problem of associating local errors with send calls (although this may also be problematic). Rather, if sending failed because it would be blocking, no error is added, and the send call also returns 0 - this is problematic as having to retry sends is a fully expected part of working with a RawDatagramSocket, so it needs to be distinguishable from the "successfully queued for sending" case.