On quinta-feira, 29 de setembro de 2016 20:43:03 PDT Dave Thaler wrote: > What is "this"?
The proposed filtering. > And no we should not prevent loopback between two sockets of the same > process. I would say it depends. If those two sockets are controlled by two separate stacks, they shouldn't filter each other's queries. Each stack is independent, so it should answer the each other's multicast queries. If they are controlled by the same stack, then the stack can decide to filter its own loopback and simply answer the query directly from the information it already had. It might be easier to do that since it may have had the query parameters before it marshalled everything, so no demarshalling. Moreover, since it's coming from the same stack, it also knows about the security parameters and can skip the redirection to unicast DTLS port. Or, the stack can be lazy and not do this short-circuiting. Instead, it would use the same code paths that it would have used for a remote query. It's less efficient time-wise, but it's simpler code-wise. > I still fail to see any reason to filter within iotivity. Let me be clear: the request needs to be answered. It just doesn't need to go down to the socket level. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
