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</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/26506ebc/attachment.html>
