Re: [Boost-users] asio UDP async receive question - how to do thisproperly?

Subject: Re: [Boost-users] asio UDP async receive question - how to do thisproperly?
From: Ákos Maróy (akos_at_[hidden])
Date: 2010-11-19 19:59:36

Cliff,

> 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).

I see. I'll re-post my question there.

> 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).

actually, I'm just implementing such protocol. but, for that, I need to
be able to recieve & process UDP packets :)

> 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.

but, my suggests that the network layer at least is able to receive
these packages, see exactly below:

> 
>> 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

but, if I add a mutex so as to store the UDP packets, then it seems the
asio async receive handler won't get all the messages anymore.

it might be that the recieved packets are dropped at the network layer,
as some internal buffer is exhausted. or it might be, that the asio
implementation just discards these?

> 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.

yes, I'd like that, but this scenario excludes the very important part
of storing & processing the messages themselves :)

> I glanced briefly through your code and didn't see any obvious problems
> (it looks nicely written, as well).

thank you.

Akos