CODEWITHSUNDEEP
clinuxsocketsmulticastrecvmmsg
Abruzzo Forte e Gentile
Abruzzo Forte e Gentile

Reputation: 14869

Reading multiple UDP messages without polling

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:

  1. 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)?
  2. 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.

Upvotes: 1

Views: 694

Answers (2)

user207421
user207421

Reputation: 311018

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.

Upvotes: 1

Rajen
Rajen

Reputation: 1009

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.

Upvotes: 0

Related Questions