As for the original concern, it will be trivial to mark a message received by multicast with a flag indicating it was received by multicast. In fact, I will include it in the my work. With additional work, that will save sending the empty response.
John Light Intel OTC OIC Development -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: Wednesday, July 01, 2015 7:45 AM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] handling multicast requests On Wednesday 01 July 2015 05:35:28 Agrawal, Sachin wrote: > The problem with current Iotivity stack is that.....every end-point in > the network will respond to this query by sending a packet (with empty > payload) even if it does not have anything useful to send. I see two possible ways out for this: 1) we really push for devices to use a directory server instead of listening on multicast. Devices that have successfully registered themselves with a directory can stop listening for multicast and will therefore not be woken up by new discoveries. The question is whether OIC will allow devices that *only* work in the presence of a directory server. 2) encode the type of service being sought in the IPv6 multicast address. Since there are 112 bits in the multicast network address, we could use some of those to encode the type of service, a portion of it or a hash of it, in such a way that it would reduce collisions on the network. No fallback for IPv4 is needed. Discovery on IPv4 will wake up all devices, which devices using IPv4 will consume more battery. Tough luck for them... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
