HI Thiago
*Please let us know if we can add steps 6-8 for fixing this issue.*
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
6) Currently this is the signature for request handler
/** Message handler for requests that is used as call-back in
coap_context_t */
typedef void (*coap_request_handler_t)(struct coap_context_t *,
const coap_queue_t * rcvd);
We should add below value to *coap_queue_t*
Bool multicast_port; // its TRUE if the packet is received in multicast
port.
7) When in *HandleCoAPRequests* we will see that multicast_port is TRUE
and the packet is UNICAST then we can ignore the request.
8) It will be processed only when multicast_port is TRUE and
the packet received also is MULTICAST.
*Please let me know your view on this*
*Regards*
*Chandan*
On Thu, Apr 2, 2015 at 1:13 AM, Thiago Macieira <thiago.macieira at intel.com>
wrote:
> On Wednesday 01 April 2015 12:28:04 Thiago Macieira wrote:
> > On Wednesday 01 April 2015 19:57:07 Carsten Bormann wrote:
> > > I didn't do the code dive yet, so I don't understand why there are two
> > > sockets (me not understanding doesn't mean it's wrong). If one is for
> > > unicast and one for multicast, I'd rather reply to the multicast on the
> > > multicast socket. The unicast socket should then simply ignore
> packets
> > > sent to the multicast address, which can be done by binding to a
> > > specific address (except apparently on Windows) and/or by looking at
> the
> > > PKTINFO of any received packet.
> >
> > I don't see why two sockets would be needed. Maybe someone can clarify,
> > though.
> >
> > A single socket is enough for sending unicast and multicast, as well as
> for
> > receiving unicast and multicast.
> >
> > The one reason I'd see for having separate sockets would be if we needed
> to
> > send from different ports. You can't send from a different port than the
> > port you've bound to.
>
> Actually, that made me think of a possible reason: imagine that you have
> two
> different applications on the same device that want to speak the OIC
> protocol.
> The two can share the multicast port address (SO_REUSEADDR) and both can
> receive the multicast packets, as if they were separate devices.
>
> However, unicast needs to be directed at a different port, so that the two
> can
> be distinguished. If we're not going to receive unicast on the same socket
> that multicast will be received, we don't need the PKTINFO ancillary data
> at
> all.
>
> Unless, of course, CoAP has provisions for sharing the same port address
> with
> another CoAP stack, in unicast mode, and including packets with reliable
> delivery. I seriously doubt it can do that.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>
--
Regards,
Chandan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150402/6718a931/attachment.html>
