Sign in to follow this  
Kobaktan

Reading multiple datagrams from UDP socket

Recommended Posts

Hello!

 

The call recvfrom reads messages from udp socket one by one, so to read 10 messages you should call recvfrom 10 times. Are there any methods or, may be, some low-level commands to read all the messages at once into a buffer? 

Share this post


Link to post
Share on other sites

UDP is about datagrams. It has no conception above that, especially not how to concat datagrams nor how to distinguish them after concatenation. 

 

However, it is not clear to me *why* you want to do so. What does "all the messages" mean exactly? A sequence of messages from the same source? A soap of messages from different sources? What should happen if one of them is missed on transmission? Such questions need to be handled as well.

 

IMHO we're speaking of stuff belonging to the application protocol layer!?

Share this post


Link to post
Share on other sites
If avoiding syscall overhead is your goal, you have to move away from the standard socket interface into platform-specific extensions. For example, you can use recvmmsg under Linux to that effect (note the double "mm", this is not a spelling error). Works reliably. Similarly, WSARecvFrom under Windows lets you specify more than one receive buffer, which should (I've not tested, no need) work that way, too.

Share this post


Link to post
Share on other sites
WSARecvFrom allows multiple buffers for purposes of scatter/gather, but only returns one message at a time.
Also, this is pretty clear, because it only returns one socket address.
Similarly, recvmmsg() only really makes sense for connected sockets, because it, also, doesn't return the addresses of any of the messages.
For the common use case of a UDP server talking to more than one client on the same socket, neither of those functions are appropriate.

Share this post


Link to post
Share on other sites

WSARecvFrom allows multiple buffers for purposes of scatter/gather, but only returns one message at a time. Also, this is pretty clear, because it only returns one socket address. Similarly, recvmmsg() only really makes sense for connected sockets, because it, also, doesn't return the addresses of any of the messages.
For the common use case of a UDP server talking to more than one client on the same socket, neither of those functions are appropriate.

I've never tried WSARecvFrom, as stated. However, recvmmsg certainly works for datagrams from different addresses. It returns a pointer to a return-value sized array of mmsghdr structures, each of which contains a msg_hdr structure and the receive length for that particular message. The msg_hdr structure contains a member msg_name, which is the originating address.

Share this post


Link to post
Share on other sites

The msg_hdr structure contains a member msg_name, which is the originating address


You're right; I missed that the recvmmsg mmsghdr pointer would have multiple entries.
Thanks for pointing that out!
WSARecvFrom unfortunately does not do the same thing.

Share this post


Link to post
Share on other sites

Hello!

 

The call recvfrom reads messages from udp socket one by one, so to read 10 messages you should call recvfrom 10 times. Are there any methods or, may be, some low-level commands to read all the messages at once into a buffer? 

 

I think you're asking the wrong question.  My guess is you worry about multiple clients sending UDP messages to a server, and you won't be able to read them all out in a timely manner for some reason.

 

I think what you really want to do is read UDP messages as they arrive (considering you won't really have 10 UDP packets arriving at the "same time"), so you should use select() (or some other method of notification) to signal you have data to be read from the UDP socket.  At that point, it's just a matter of calling recvfrom() as you get notified of a packet arriving, and determining which client sent the data.

Share this post


Link to post
Share on other sites
It depends on the throughput expected.
The cost of a system call is on the order of 1 microsecond, so at 1 million datagrams, you will saturate one core just reading.
And if you need locking to hand off work to other threds, you may be multiplying the number of system calls.

Of course, you'd need 10 Gbit networking to acctuall ge million packets across in a second, and that in turn assumes your networking driver and hardware are 100% efficient...
But there exists systems where paying 1/20th as many syscalls by reading 20 incoming packets at a time actually does reduce CPU load!
The question is whether the OP is at that scale or not -- we have no way of knowing.

Share this post


Link to post
Share on other sites

It depends on the throughput expected.
...
The question is whether the OP is at that scale or not -- we have no way of knowing.

hplus, you know more about networking than me, no doubt, but, reading his initial question, I feel pretty safe in assuming he isn't in need of that kind of throughput and it's is more of a beginner networking question.

 

Either way, we now have both bases covered.

Share this post


Link to post
Share on other sites

There is some middle processing (often done in a separate thread) where all the "Reliability" issues (if any) are handled and channeling/organizing info down different processing streams (ie- looking for client signals like close/byebye msgs versus the running data streams,  or multiple packet block completion ) can be done  before it gets to the higher level game processing.

 

If you have multiple packets making up one message then you need data markings within the packets to allow the receiver to determine if the whole message HAS arrived (intact) to then be passed-on and  actioned (at higher level or whatever).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this