Reading multiple UDP messages without polling

Question

I would like to use the recvmmsg call to read multiple UDP messages from ONE single socket at once. I'm reading data from a single multicast group.

When I read TCP data, I usually use poll/select with a non-blocking socket (and timeout) to be notified when that is ready to be read. I follow this approach as I am aware of the issue of spurious wakeup and potential troubles of having a blocking socket.

As my application must be very quick, if I follow the same approach with recvmmsg I will introduce an extra system call (poll/select) that might slow down the execution.

So my two questions are the following:

With UDP, can I safely read from BLOCKING sockets using recvmmsg without poll/select or do I have to apply the same principle I've used for TCP (non-blocking+poll)?
Suppose I have a huge amount of multicast traffic, would you go for non-blocking socket + recvmmsg only (no poll) and burn a lot of CPU?

I am using Linux: CentOS 7 and Oracle Linux.

Note that whether you use poll/select + nonblocking sockets would depend on whether you need to handle several sockets or reading/writing concurrently, not whether you're using TCP or UDP. — nos, Aug 21 '15 at 06:46

user207421 · Answer 1 · 2015-08-22T02:22:41.900

1

You can always use blocking mode, with both TCP and UDP sockets.

If you want to impose a read timeout there is setsockopt() with the SO_RCVTIMEO option.

I follow this approach as I am aware of the issue of spurious wakeup

What spurious wakeup? Never seen it in 25 years of network programming.

and potential troubles of having a blocking socket.

Never heard of those either.

Using select() and non-blocking mode with a single socket is pointless unless your platform doesn't support SO_RCVTIMEO. It's an extra system call, for a start.

edited Aug 22 '15 at 02:22

answered Aug 21 '15 at 06:35

user207421

305,947
44
307
483

Thanks a lot! I forgot about it and you are right!! What about the performance? I might be wrong but I read somewhere that this setting is not advisable (can't remember where I did read it..I'll search for it) – Abruzzo Forte e Gentile Aug 21 '15 at 06:47
Never heard that in 20+ years of network programming. – user207421 Aug 21 '15 at 07:00
@EJP - FUD. 'blocking' sounds bad, so it must be bad. – Martin James Aug 21 '15 at 09:12
@MartinJames Yeah, two system calls must be better than one :-| – user207421 Aug 21 '15 at 12:13

score 0 · Answer 2 · edited Aug 21 '15 at 07:00

The option of using blocking or non-blocking depends on what is the final purpose of the application. - Say it's just a sample chat application showing the usage of UDP combined with TCP then you can use either. - But if you are planning to make this module a part of highly used application with lots of data flowing then probably creating multiple threads/processes to handle different tasks will come in handy. The parent thread will to wait for the message but for processing it will spawn a different child thread and hence make the parent available for the next message.

But in a nutshell I don't see any issue with your first option of using a blocking socket without poll/select for a UDP application considering it's just for homework purposes.

Reading multiple UDP messages without polling

2 Answers2