Chandan,
Can you do one thing first? Forbid sending CONFIRMABLE requests on the multicast port. It is a violation of the RFC7252, section 8.1 Messaging Layer: ?A multicast request is characterized by being transported in a CoAP message that is addressed to an IP multicast address instead of a CoAP endpoint. Such multicast requests MUST be Non-confirmable.? Pat From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Chandan Sent: Tuesday, March 31, 2015 2:27 PM To: iotivity-dev at lists.iotivity.org Cc: raj.rajan at samsung.com Subject: [dev] Timing issue in handling COAP request in HandleCoAPRequests HI ALL Below is an analysis of defect IOT-191 (https://jira.iotivity.org/browse/IOT-191) Step - 1 On client side, perform a multicast discovery using command occlientslow -u0 -t3 which means multicast with CON messages Step - 2 In server side we register COAP request as coap_register_request_handler(gCoAPCtx, HandleCoAPRequests); So this request is received in both sockets i.e gCoAPCtx->sockfd and gCoAPCtx->sockfd_wellknown Expected Scenario - i) HandleCoAPRequests is invoked for gCoAPCtx->sockfd ii) HandleSingleResponse gets invoked for this but response is not sent yet. iii) HandleCoAPRequests is invoked for gCoAPCtx->sockfd_wellknown but it gets rejected at HandleStackRequests as the token is same as received in step-i iv) Unicast response is sent from the server only ONCE from HandleSingleResponse . BUG Scenario - i) HandleCoAPRequests is invoked for gCoAPCtx->sockfd ii) HandleSingleResponse gets invoked for this and RESPONSE is SENT 1st time. iii) HandleCoAPRequests is invoked for gCoAPCtx->sockfd_wellknown and its treated as a new request iv) Unicast response is sent from the server for 2ND time in HandleSingleResponse . There can be below possible solutions to handle this timing problem. Please suggest me which is good option as I am new to IOTIVITY. option - 1 We can cache the requests received for a certain time period so that we can avoid sending both unicast n multicast response by comparing request information. Decision can be taken to ignore duplicate request. But difficult to decide the time to cache. * option - 2 While we detect that coap://224.0.1.187 <http://224.0.1.187> </span>/oc/core?rt=alpha.light is received with port number 5683 then we should not send response from the invocation done for gCoAPCtx->sockfd As it will definitely be sent from the well known socket. -- Regards, Chandan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150401/7c3c4e3e/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7198 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150401/7c3c4e3e/attachment.p7s>
