Chandan wrote: > HI ALL > > Can we have below approach for solving this issue? > > If a server does decide to respond to a multicast request, it should > not respond immediately. Instead, it should pick a duration for the > period of time during which it intends to respond. For the purposes > of this exposition, we call the length of this period the Leisure. > The specific value of this Leisure may depend on the application or > MAY be derived as described below. The server SHOULD then pick a > random point of time within the chosen leisure period to send back > the unicast response to the multicast request. > > > It should have a timer before which server should not respond.
Right. > *If the same request gets already processed in timer value then we can ignore > the request.* But that should never happen (and if it did happen, it would be subject to the same timer rule). We'll need to do multicast detection as I described in previous messages (see also the section "# Binding to specific lower-layer APIs" in http://svn.tools.ietf.org/svn/wg/lwig/draft-ietf-lwig-coap.mkd -- soon to be https://tools.ietf.org/html/draft-ietf-lwig-coap-02). Gr??e, Carsten
