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. *If the same request gets already processed in timer value then we can ignore the request.* Please let me know your view. Regards Chandan On Wed, Apr 1, 2015 at 8:33 PM, Carsten Bormann <cabo at tzi.org> wrote: > Hi Pat, > > Lankswert, Patrick wrote: > > Where supported IPV6_RECVPKTINFO is a nice alternative where it is > supported, > > Yes, but only where it is supported :-) > (In my parts of the woods it's near universal, but I'm not even close to > having the widest range of systems available to me). > > > but the last time that I looked there was not a good way to specify > which interface that a packet should be sent *from* other than having a > socket bound to each interface. > > For a split-horizon system (e.g., a firewall with multiple interfaces > with similar routes), just binding the sockets to an address may not work: > The kernel is still using the routing table to find the outgoing > interface, and that may have a "better" (but still unwanted) path via an > interface with an address that the socket is not bound to. > > Hence hacks such as SO_BINDTODEVICE (which appears to be Linux only). > According to RFC 3542 [1], IPV6_PKTINFO does have an outgoing interface > index. I haven't done the necessary research here to see how well that > is implemented. It will probably pay to talk to the DHCP and DNS > implementer community; they have lots of experience with this issue. > > Gr??e, Carsten > > [1]: http://tools.ietf.org/html/rfc3542#section-6 > -- Regards, Chandan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150401/8e831c34/attachment.html>
