I went to JIRA IOT-109, and I couldn?t find what branch this applies to. Seeing the CoAP references, I?m guessing its master branch. If so, it will likely change behavior after the merge with Connectivity Abstraction.
John From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Chandan Sent: Tuesday, March 31, 2015 11:27 AM 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/20150331/8a409e2b/attachment.html>
