From: "Ákos Maróy"
b sent 20000 messages a received 1981 messages
Depending on a lot of factors, this is not surprising. If you're sending the datagrams faster than you can receive and process them, this will happen. I've found that with UDP it's difficult to get 0% loss, even with a controlled environment (internal network, no Internet or WAN hops) and a consistent flow of datagrams. Check the list archives for previous discussions on this topic (there's quite a few, although the discussions might be on the Asio Users list instead of Boost Users list). If you need reliable data transfer, you need to use another protocol (usually TCP). If you need "closer to 100%" you will need to do something like metering the sending side (more so than you've done in your code), or put in simple "detect loss and re-send" functionality (although the more sophisticated the "detect loss and re-send" the closer the logic becomes to TCP). All of the pieces in the network chain take advantage of UDP being an unreliable protocol and can drop packets on a whim. This includes the OS protocol stack, the NIC driver code and firmware, and switches and routers in the network.
If I remove the processing of messages in threa_func(), the results are markedly better:
./async_asio b sent 20000 messages a received 19963 messages
This loss rate (less than 1%) is closer to what I routinely see, on controlled (internal) networks that are nowhere close to being congested. It's also (informally) similar to numbers I've seen from others that have used UDP for various needs. I've seen messages from others that have achieved better loss rates, but it took some real work (tuning OS buffers, driver parameters, etc). This loss rate works well for many, many applications. I glanced briefly through your code and didn't see any obvious problems (it looks nicely written, as well). Cliff