On 24.4.2015, at 7.46, Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: >> You can process TLVs invididually (the length is in second byte received), >> or in small chunks. TLV processing definition has only one dependency on >> other TLVs (node data has to have respective node state ’nearby’, for >> undefined nearby) in the stream, and the node connection TLV must be >> remembered per message (=whole TCP stream or single UDP datagram) if >> encountered. > OK, so the process will just keep running until the TCP session closes, > as I understand it. Which incidentally means that you tie up the listen port, > doesn't it? In GDNP we think of more transactional messages, which is why > I wasn’t understanding DNCP properly.
I am not sure what do you mean with listen port; the TCP connection is (proto, ip1, p1, ip2, p2) tuple, and one listen port can obviously produce as many TCP connections as there are connecting clients (as long as you do not run out of the tuples). However, the duration of the TCP connection is intentionally not specified in the core protocol; a DNCP profile _may_ tie e.g. peer state to it’s lifetime (in which case longer durations are preferable), but it also may not. >> Any suggestions on how to rephrase that to be more clear? > Maybe you need an outline description of the DNCP state machine. Well, that is intentionally omitted. The mandatory ’state machine’ should be simply Trickle caused network state messages, and then processing triggered by them (the MUSTs in the processing of received TLVs). This is so that ’simple’ implementation is indeed simple (in -03 we will probably send today, we are removing the # of TLVs that need to be handled from 6 to 5 by removing the node data altogether, as it had implicit dependency on node state anyway to be useful), Given the per-TLV semantics, optimizations such as more proactive spreading of state _will_ be supported by simple clients, although they are not even specified in the DNCP base spec yet, we have just some ideas for implementation purposes. Anyway, sending updated -03 probably later today or early next week, it should hopefully make the per-TLV nature bit more clear (and also address some other things). Cheers, -Markus _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
