On 22/10/10 14:42, Igor R wrote:

I run your code (Win7, MSVC10, boost 1.44), and I can't reproduce the issue you describe, the output is always: b sent 2000 messages a received 2000 messages

interesting. I'm using boost 1.40 on a Linux box (Ubuntu 10.04 64bit), and we also tried with boost 1.40 on a Windows box, with the same results. maybe I should try with a more recent boost version

Anyway, if I read your code correctly, you assume that all these messages should be sent/received within 1 second, don't you? What if you increase this value?

this is already the result of increasing this sleep period. the results are the same for 100ms already, raising to 1000ms didn't make a difference, doubt longer values would..

Igor,

I run your code (Win7, MSVC10, boost 1.44), and I can't reproduce the issue you describe, the output is always: b sent 2000 messages a received 2000 messages

I gave it a shot using boost 1.44, freshly downloaded & compiled, but I get the same results. the pattern is the same: up until a certain number of packets, everything is received. but there's an obvious breaking point, after which only a few packets will be received, maybe less than five. one way I could make it send / receive all the packets was to add a millisecond of sleep after each send: for (unsigned int i = 0; i < 2000; ++i) { std::stringstream sstr; sstr << i; b.send(endp_a, sstr.str()); boost::this_thread::yield(); boost::this_thread::sleep(boost::posix_time::milliseconds(1)); } this indicates the problem to be a threading issue. but wouldn't a yield() be enough? putting in a 1ms sleep every 100 sends also works most of the time: for (unsigned int i = 0; i < 2000; ++i) { std::stringstream sstr; sstr << i; b.send(endp_a, sstr.str()); if (i % 100 == 0) { boost::this_thread::yield(); boost::this_thread::sleep(boost::posix_time::milliseconds(1)); } } but putting the 1ms sleep in every 1000 sends will break things again. the results seem to be the same with boost 1.40 and 1.44.

Anyway, if I read your code correctly, you assume that all these messages should be sent/received within 1 second, don't you? What if you increase this value?

giving 1 seconds or 5 seconds gives the same result. Akos

Yuri,

void handle_send_to(const boost::system::error_code& error, size_t /*bytes_sent*/) { if (error) { std::cout << "send error!" << std::endl; }

++messages_sent_;

socket_.async_receive_from( boost::asio::buffer(data_, max_length), sender_endpoint_, boost::bind(&server::handle_receive_from, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); }

2000 times "async_receive_from" in sending server it's not so good, i think. Without it all work fine.

good point. as just stated in the earlier mail, this code was a leftover from a sample I started out with. now having removed it seems to have solved my problem. thanks, Akos

Martin, thanks for your feedback.

I am no ASIO expert, but a few things came to mind:

1) As far as I know, it is not safe to do a async_send operation on a socket before the previous async_send operation has completed. I have seen this mentioned somewhere in the documentation, but can't find the place now.

it might be. then again, all send events seem to complete find, as the send callback is called the proper number of times.

2) Line 56: The logic in handle_send_to seems flawed. It issues a async_receive_from()? I would expect it to either send another UDP packet or just check the error code from the original send operation.

this is a leftover from the boost asio sample code I copied it over from, see here: http://www.boost.org/doc/libs/1_44_0/doc/html/boost_asio/example/echo/async_... removing it actually solves my issue. wow - I wouldn't have thought :) now I'm hitting the following barriers: b sent 200000 messages a received 199597 messages b sent 2000000 messages a received 1990728 messages these both seem to be over 99% fidelity, which is, well, sort of OK :)

3) Line 116: The lifetime of the buffer passed to send() may end before the async operation completes. This will likely not cause the issues seen here, but worth mentioning.

actually an asio::buffer object is created in send(), which copies the contents over. this is the same pattern as used in the same sample code quoted above.

Have you tried - just for debugging - changing the send() operation to be synchronous?

actually haven't. Akos

On 22/10/10 17:08, Michael Caisse wrote:

On 10/22/2010 7:53 AM, Ákos Maróy wrote:

...

actually an asio::buffer object is created in send(), which copies the contents over. this is the same pattern as used in the same sample code quoted above.

This is a common error. The asio::buffer simply wraps the memory and provides a starting location and size. You still must manage the memory.

http://www.boost.org/doc/libs/1_44_0/doc/html/boost_asio/reference/buffer.ht...

thanks for pointing this out. it would be nice to get rid of this wrong pattern in the 'official' example code too :)

Michael,

The code examples do this correctly. It uses a private data member in the class named data_. The pattern uses bind and shared_from_this in the handlers to ensure lifetime. That is the correct way.

You may find my boostcon10 slides useful. Ownership of memory buffers is part of the proactor model.

http://www.objectmodelingdesigns.com/boostcon10/ http://www.blip.tv/file/4171562/

thank you - I'll take a look.. Akos

Rutger,

Not sure if it's related to your problem, but AFAICT you are not managing your resources in a correct way. Everything passed to an 'async_' function should outlive the full async operation. E.g., in your 'send' function you use a RValue string -- this will most probably not outlive the async_send_to operation.

thanks for the observation. as stated in an earlier e-mail, this code comes from this sample: http://www.boost.org/doc/libs/1_44_0/doc/html/boost_asio/example/echo/async_...

Perhaps related to your problem, is that you are counting the number of "received_from" callbacks, not the number of received messages. Couldn't it be that you receive multiple messages in one callback?

my presumption would be that this is called each time a message is received. also, when saving & printing out these messages, it is clear that messages are received exactly as they are sent. Akos