CODEWITHSUNDEEP
socketsboostasynchronousboost-asio
Alberto Toglia
Alberto Toglia

Reputation: 391

Boost Asio UDP retrieve last packet in socket buffer

I have been messing around Boost Asio for some days now but I got stuck with this weird behavior. Please let me explain.

Computer A is sending continuos udp packets every 500 ms to computer B, computer B desires to read A's packets with it own velocity but only wants A's last packet, obviously the most updated one.

It has come to my attention that when I do a:

mSocket.receive_from(boost::asio::buffer(mBuffer), mEndPoint);

I can get OLD packets that were not processed (almost everytime).

Does this make any sense? A friend of mine told me that sockets maintain a buffer of packets and therefore If I read with a lower frequency than the sender this could happen. ¡?

So, the first question is how is it possible to receive the last packet and discard the ones I missed?

Later I tried using the async example of the Boost documentation but found it did not do what I wanted.

http://www.boost.org/doc/libs/1_36_0/doc/html/boost_asio/tutorial/tutdaytime6.html

From what I could tell the async_receive_from should call the method "handle_receive" when a packet arrives, and that works for the first packet after the service was "run".

If I wanted to keep listening the port I should call the async_receive_from again in the handle code. right?

BUT what I found is that I start an infinite loop, it doesn't wait till the next packet, it just enters "handle_receive" again and again.

I'm not doing a server application, a lot of things are going on (its a game), so my second question is, do I have to use threads to use the async receive method properly, is there some example with threads and async receive?

Upvotes: 0

Views: 4262

Answers (5)

olmerg
olmerg

Reputation: 435

I think that I have your same problem, to solve the problem I read the bytes_available and compare with packet width until I receive the last package:

boost::asio::socket_base::bytes_readable command(true);
socket_server.io_control(command);
std::size_t bytes_readable = command.get();

Here is the documentation.

Upvotes: 0

hookenz
hookenz

Reputation: 38879

You're going about it the wrong way. The receiving end has a FIFO queue. Once the queue gets filled new arriving packets are discarded.

So what you need to do on the receiver is just to keep reading the packets as fast as possible and process them as they arrive.

Your receiving end should easily be able to handle receiving a packet every 500ms. I'd say you've got a bug in your code and from what you describe yes you do.

It could be this, make sure in handle_receive that you only call async_receive_from if there is no error.

Upvotes: 0

guangzhuwu
guangzhuwu

Reputation: 11

P2engine is a flexible and efficient platform for making p2p system development easier. Reliable UDP, Message Transport , Message Dispatcher, Fast and Safe Signal/Slot...

Upvotes: 0

Len Holgate
Len Holgate

Reputation: 21616

With Windows (certainly XP, Vista, & 7); if you set your recv buffer size to zero you'll only receive datagrams if you have a recv pending when the datagram arrives. This MAY do what you want but you'll have to sit and wait for the next one if you post your recv just after the last datagram arrives ...

Since you're doing a game, it would be far better, IMHO, is to use something built on UDP rather than UDP itself. Take a look at ENet which supports reliable data over UDP and also unreliable 'sequenced' data over UDP. With unreliable sequenced data you only ever get the 'latest' data. Or something like RakNet might be useful to you as it does a lot of games stuff and also includes stuff similar to ENet's sequenced data.

Something else you should bear in mind is that with raw UDP you may get those datagrams out of order and you may get them more than once. So you're likely gonna need your own sequence number in their anyway if you don't use something which sequences the data for you.

Upvotes: 2

Jean-Paul Calderone
Jean-Paul Calderone

Reputation: 48315

One option is to take advantage of the fact that when the local receive buffer for your UDP socket fills up, subsequently received packets will push older ones out of the buffer. You can set the local receive buffer size to be large enough for one packet, but not two. This will make the newest packet to arrive always cause the previous one to be discarded. When you then ask for the packet using receive_from, you'll get the latest (and only) one.

Here are the API docs for changing the receive buffer size with Boost:

http://www.boost.org/doc/libs/1_37_0/doc/html/boost_asio/reference/basic_datagram_socket/receive_buffer_size.html

The example appears to be wrong, in that it shows a tcp socket rather than a udp socket, but changing that back to udp should be easy (the trivially obvious change should be the right one).

Upvotes: 2

Related Questions