HI Vijay Thanks for the input. I will go through the same and update
*Regards* *Chandan* On Fri, Apr 3, 2015 at 3:44 PM, Kesavan, Vijay S <vijay.s.kesavan at intel.com> wrote: > Chandan ? you are referring to code from master which is going change > significantly once connectivity abstraction layer is introduced. I suggest > you first check to see if the issue occurs on the CA branch as well and > then work out a strategy to distinguish between unicast and multicast. > > > > --Vijay > > > > *From:* iotivity-dev-bounces at lists.iotivity.org [mailto: > iotivity-dev-bounces at lists.iotivity.org] *On Behalf Of *Chandan > *Sent:* Thursday, April 02, 2015 11:22 AM > *To:* uzchoi at samsung.com; iotivity-dev at lists.iotivity.org > *Subject:* [dev] Fwd: Timing issue in handling COAP request in > HandleCoAPRequests > > > > HI Mr.Choi > > > > Please suggest if this could be one approach to fix the issue. > > *IOT-191 (*https://jira.iotivity.org/browse/IOT-191*)* > > > > > > 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. > > > > *Regards* > > *Chandan swarup Patra* > > *chandan.sp at samsung.com <chandan.sp at samsung.com>* > > > > > > > > > > > > On Thu, Apr 2, 2015 at 10:16 PM, Thiago Macieira < > thiago.macieira at intel.com> wrote: > > On Thursday 02 April 2015 21:22:18 Chandan wrote: > > 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* > > Hi Chandan > > I am not familiar with the internal API to comment on this. > > Maybe someone else can. Erich, Pat, Uze? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > > > -- > > Regards, > Chandan > -- Regards, Chandan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150403/b1d29af4/attachment.html>
