Search code examples
csocketsudpportabilitysendto

Multiple sendto() using UDP socket

I have a network software which uses UDP to communicate with other instances of the same program. For different reasons, I must use UDP here.

I recently had problems sending huge ammounts of data over UDP and had to implement a fragmentation system to split my messages into small data chunks. So far, it worked well but I now encounter an issue when I have to send a lot of data chunks.

I have the following algorithm:

  1. Split message into small data chunks (around 1500 bytes)
  2. Iterate over the data chunks list and for each, send it using sendto()

However, when I send a lot of data chunks, the receiver only gets the first 6 messages. Sometimes it misses the sixth and receives the seventh. It depends.

Anyway, sendto() always indicates success. This always happen when I test my software over a loopback interface (127.0.0.1) but never over my LAN network.

If I add something like std::cout << "test" << std::endl; between the sendto() then every frame is received.

I am aware that UDP allows packet loss and that my frames might be loss for a lot of reasons and I suppose it has to do with the rate I am sending the data chunks at.

What would be the right approach here ?

  • Implementing some acknowledgement mechanism (just like TCP) seems overkill.
  • Adding some arbitrary waiting time between the sendto() is ugly and will probably decrease performance.
  • Increasing (if possible) the receiver UDP internal buffer ? I don't even know if this is possible.
  • Something else ?

I really need your advices here.

Thank very much.

Additional information as requested

The reason I must use UDP is because I have several constraints:

  1. TCP doesn't work well with NAT traversal (at least without a specific configuration)
  2. Some messages can be lost. Some others can't.
  3. The message delivery order doesn't matter.
Solution

  • Implementing an acknowledgement mechanism sounds like exactly what you need to do. That way you can ensure that no more than N packets are "in-flight" at once, and you can retransmit packets that have gone unacknowledged for too long.