1

I am using recvmmsg() to receive the multicast traffic.

After researching online, I figured that I could use setsockopt with IP_PKTINFO on, and then ask glibc to populate the ancillary data, which includes the destination address.

Is a way to ask glibc or whatever to populate the destination address but not any other ancillary data?

P.S. The way to extract all ancillary data is here: Get destination address of a received UDP packet

Community
  • 1
  • 1
Hei
  • 1,844
  • 3
  • 21
  • 35
  • The destination address should be the multicast group address. Why isn't that the answer? – user207421 Sep 13 '13 at 09:50
  • Correct. However, the solution in the link requires a for-loop to iterate through an array of ancillary data. I am looking for a solution that it doesn't involve the for-loop but retrieves in O(1). – Hei Sep 13 '13 at 17:10
  • You've changed the question. All that data is populated by recvmsg(), not by the loop. That is the answer to the question you originally asked. The data is such that you have to traverse it, bad luck. Have you check to see actually is anything else in there other than the destination address? – user207421 Sep 13 '13 at 23:44
  • my original question is "I would like to know whether there is a way to ask glibc or whatever to populate the destination address but not any other ancillary data", which implies a possible O(1) operation as there would be just one element. Currently, the destination is populated in the first element in the loop *probably by luck*. Hence, I am looking for a document that tells me whether there is no guarantee to have the destination address as the first element. – Hei Sep 14 '13 at 13:43
  • Is there anything *else* in the data structure? If not, the operation is already O(1). And you didn't say 'or whatever'. – user207421 Sep 15 '13 at 23:47
  • It is the first and *might* be only element. However, I am looking for a document that explicitly states that the destination address will be the first element at least (if not the only element). What do you mean by "didn't say 'or whatever'"? – Hei Sep 16 '13 at 09:21
  • What I mean by 'you didn't say "or whatever"' is that you didn't say 'or whatever', contrary to your statement above where you claimed exactly that. And now when you say 'might be', why don't you know? What happened when you tested it? – user207421 Sep 17 '13 at 10:22
  • Ok. So I know as a fact on my box with specific glibc and kernel version that the first element has the destination address. However, if there is a document, I will be more comfortable to *assume* the destination address is the first element. If the later version of glibc or kernel changes, that's fine as well as I can refer to the document again to figure what to do. Without the document, my code might break without knowing the reason after I upgrade glibc or kernel. – Hei Sep 17 '13 at 23:59
  • In my test, I never tried to print out the max number of elements. However, the number of elements isn't the key point here although it is relevant. However, the document is key point here. – Hei Sep 17 '13 at 23:59
  • I shouldn't say "without knowing the reason". I should say I won't know without a huge financial penalty as I am working on a high frequency trading system that I can't *assume* a lot of things. – Hei Sep 18 '13 at 00:01
  • If you only ask for IP_PKTINFO , that will be the only ancillary data you get. But it's not like that for loop will impact your performance in any way you will be able to measure no matter how high requency your trading needs to be. – nos Mar 02 '14 at 01:39

0 Answers0