2
votes

I want to read data from a udp socket asynchronously which is taken as a server socket and is listening on a certain port.

socket_->async_receive_from(
    boost::asio::null_buffers(),
    sender_endpoint_,
    boost::bind(&UdpSocketServer::HandleReceive, 
                shared_from_this(), 
                boost::asio::placeholders::error,
                boost::asio::placeholders::bytes_transferred
    )
); 

the question is: sender_endpoint_ is always 0.0.0.0:0 while received some data from client. when I use boost::asio::buffer(recv_buffer_) in place of boost::aiso::null_buffers(), the sender_endpoint_ comes right. I try to search this wired case in google, but cant figure it out. Since anybody encountered the case before? or anybody can help? thanks very much.

1
Interesting edge case. I haven't looked into this, but +1 for the question - sehe

1 Answers

0
votes

You are not supposed to use null_buffers in such a way, yet.

The null_buffers type is only intended for use with async_read/write_some() on the "lowest layer", i.e. the socket or descriptor. It is not part of any of the stream type requirements, and so not supported by composed operations such as async_read. Please read this ticket for more information.

Given the tracker above the following may be transient, but the way the notifications behave now is that you get a (superfluous) HandleReceive notification with zero bytes received and an empty sender_endpoint_ - a notification that you can discard, and then a subsequent HandleReceive notification with the correct endpoint information.