On 23.2.2015, at 18.51, Juliusz Chroboczek <[email protected]> wrote: > Another question -- is it possible to participate in Trickle-driven > flooding without building the full topology graph? > > If not, that's a little disappointing, since Trickle is designed so that > it can be implemented while knowing just my immediate neighbours. But it > looks to me like I cannot do the activities mandated in Section 5.4 > without building full topology.
You are coming up with same things I have thought about quite a bit too. The current answer based on strict reading of the spec is no. The reason isn’t 5.4 (it is just a SHOULD, because you can implement something stubby that just relies on LNS being complete list of nodes known by neighbors). Why is it impossible then? Simply because the 5.2 specifies that node data requests MUST be always responded to (as you may not want to actually store any data about anyone else than yourself to start with). I have been debating with myself how to change this. Is this desirable to be changed? Probably so. Simplest change to achieve this would be simply to add ‘if available’ to 5.2 (and perhaps to note in section 4 that the data model is not really normative), and some sort of flag about stubby behavior (notably, assume that there is no HNCP talkers behind the node so it is asked only about it’s own state). With this scheme, you can have: [1] ’really stubby HNCP write-only’ which does not store anything except (possibly empty-ish set) of it’s own published node data and one neighbor - the non-stubby router it has chosen. All it needs to know about the other nodes is just a copy of LNS stored somewhere so it can interact with non-stubby router (and pretend nobody else exists so no need for keeping track of even other local neighbors). However, I am not sure if this scheme is actually sensible; in practise, if you want ‘write-only’, you really want to just have some exchange with a genuine long-lived HNCP participant with a TTL + early revocation scheme. [2] ’bit less minimal but still stubby’ HNCP could just keep all node data that has reference in LNS of it’s peers but otherwise work like [1]. Relatively useful, and much simpler to implement than whole thing still. Note that both of these ’stubby’ variants need ’non-stubby’ one to leech off on the same link. Both would be fine to stick in e.g. host though. Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
