Sachin, The change I suggested is already in my code, which means the message is tagged with a Multicast flag.
I don't thoroughly understand the original problem or the server code, so once my code is merged, I will re-assign the Jira ticket to you. :) John -----Original Message----- From: Agrawal, Sachin Sent: Wednesday, July 01, 2015 8:50 AM To: Light, John J; Macieira, Thiago; iotivity-dev at lists.iotivity.org Subject: Re: [dev] handling multicast requests On 07/01/2015 08:15 AM, Light, John J wrote: > 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. Thanks John. I have assigned the Jira ticket to you :). > > John Light > Intel OTC OIC Development > > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org > [mailto:iotivity-dev-bounces at lists.iotivity.org] 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. > Yes. That would be helpful too. > 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. > Yes. This can be an alternative mechanism to do selective discovery. > 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 > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev >
