On Wednesday 01 April 2015 23:05:43 Chandan wrote:
> HI Thiago
>
> Please confirm if you are suggesting this
> 1) Use IP_PKTINFO to detect the packet type whether it is MULTICAST or
> UNICAST.
Hi Chandan
Yes, that is what I am suggesting. More specifically, you'll need to:
1) if the socket is IPv6, do:
int v = 1;
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &v, sizeof(v))
2) if the socket is IPv4, do:
int v = 1;
#ifdef IP_PKTINFO
// Linux, OS X, Windows, NetBSD, Solaris
setsockopt(fd, IPPROTO_IP, IP_PKTINFO, &v, sizeof(v));
#elif defined(IP_RECVDSTADDR)
// FreeBSD, OpenBSD, DragonflyBSD
setsockopt(fd, IPPROTO_IP, IP_RECVDSTADDR, &v, sizeof(v));
setsockopt(fd, IPPROTO_IP, IP_RECVIF, &v, sizeof(v));
#endif
3) convert all the recvfrom calls into recvmsg [*]
4) allocate enough buffer space to receive ancillary data consisting of either
an in6_pktinfo, an in_pktinfo or, for the three BSDs that don't support
IP_PKTINFO, an in_addr and a struct sockaddr_dl.
5) decode the ancillary data as appropriate
[*] You'll probably revamp the OCRecvFrom function instead and you'll probably
replace it throughout the code. Some research will be needed here, I don't
know how to best address this issue.
I do recommend you keep a function wrapping recvmsg anyway and remove *all*
calls to recvfrom from the source code, anywhere. That's because Windows
winsock doesn't have "recvmsg", but instead it's WSARecvMsg, which has a
different signature and API. When we get around to Windows code, it's best to
have that abstracted.
How I wish we could use QUdpSocket... I've already done all of this work.
> 2) Then start the timer for processing the request
> 3) If the request is received as unicast packet and gets processed(response
> sent) then we can ignore
> the request received in well known socket as multicast packet.
These are beyond me.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
