Personally, I would prefer keeping it simple. Don?t filter loopback, let you discover yourself. If non-IP technologies (which aren?t supported in the OCF spec) don?t loop back themselves, then the adapter code should do so for consistency. But if you run IP over those technologies, the IP stack will loop back multicast.
From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Jaewook Jung Sent: Monday, October 10, 2016 5:45 PM To: Thiago Macieira <thiago.macieira at intel.com> Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Multicast loop back on IP I was thinking that multicast loopback should be totally blocked. Not be processed on higher layer instead. Could you explain any reason why the multicast packet must be delivered to itself? I don't find any practical one. If the multicast loopback is blocked, unicast loopback never happens since we don't discover the own resource. --------- Original Message --------- Sender : Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> Date : 2016-10-10 17:49 (GMT+9) Title : Re: [dev] Multicast loop back on IP On segunda-feira, 10 de outubro de 2016 08:06:33 CEST Jaewook Jung wrote: > I implemented to filter the loopback packet, comparing with the own ip+port > which has been got when ip adapter becomes enabled. Then you're missing half of the change. We agreed that filtering the looped back packets makes sense *because* we would need to insert a loop back of our own, higher in the stack, given that other technologies won't loop back. Queries sent to multicast must still match local resources. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center [cid:image001.gif at 01D22324.0F518040] [http://v70ext.samsung.net/mail/ext/v1/external/status/update?userid=jw0213.jung&do=bWFpbElEPTIwMTYxMDExMDA0NDQ4ZXBjbXMxcDFlMWQzN2M1YTIwMTVlYmQ1YmRiNjVmZTU2NWExYWQ5OCZyZWNpcGllbnRBZGRyZXNzPWlvdGl2aXR5LWRldkBsaXN0cy5pb3Rpdml0eS5vcmc_] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161011/3b0a32e2/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13402 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161011/3b0a32e2/attachment.gif>
