On 4.7.2015 0.28, Juliusz Chroboczek wrote:
Markus, Steven,
Section 4.4 of DNCP says that the NODE-STATE TLVs sent in reply to
a REQ-NODE-STATE MUST NOT contain the optional part. Why is that? If
I've recently republished my own data (e.g. because I gained a neighbour),
it makes sense to me to send my own NODE-STATE in order to avoid a round-trip.
I assume you are talking about REQ-NET-STATE. The underlying problem
here is that (generally speaking) there is no way to know if they have
received the state already from someone else even if you did change it
recently.
Especially given large node datas, the difference is relatively large.
Now that we discuss it, I think SHOULD NOT might be correct, though; if
you haven't shared it with _anyone_, obviously first one is at least
unknown to the rest of the network.
Still in the same section, when a duplicate node-id is detected, the new
seqno chosen myst be significantly higher than the one received. Why is
that? Is +1 not enough? (I'm using +42 right now, of course.)
There may be more than one update from previous reboot cycle in the
network still; it is not even bounded, given infinitely large network,
but 'few' is enough in real world, and so should 42.
Funnily enough I thought +1 was enough at first too.
The DNCP profile MUST provide guidance about how to deal with node-id
collisions. Where is that guidance provided in HNCP?
o HNCP uses opaque 32-bit node identifiers
(DNCP_NODE_IDENTIFIER_LENGTH = 32). A node implementing HNCP
SHOULD generate and use a random node identifier. If using a
random node identifier and there is a node identifier collision,
the node MUST immediately generate and use a new random node
identifier which is not used by any other node.
The expression defining the circular ordering is written in C syntax, but
I think it assumes different priorities than C. Please put brackets
around the bitwise conjunction.
Actually I do not even think it is C; at least, for it to be valid C,
some bonus parentheses and 1<<X should replace 2^ portions.
eg what we use is ((((uint32_t)(a) - (uint32_t)(b)) & ((uint32_t)1<<31))
!= 0)
Hmm. Wonder if removing the guidance altogether is the preferable choice
here.
Section 4.5 suggests sending a unicast REQ-NETWORK-STATE when receiving
ENDPOINT. If adding the peer fails (say, out of memory), won't this cause
a livelock?
Given stream case, yes, as there is no guarantee of second one ever
showing up.
For datagrams, next ENDPOINT should do it, no?
Shouldn't the first part of 4.5 be moved into 4.4?
Hm, it might improve the readability a bit :)
4.6, MUST be traversed Either immediately... Is it not better to say that
it must be traversed before the next message is scheduled to be sent?
Not really, as in some cases, you may have relatively long next
keepalive or Trickle timer, and waiting until then to discover that you
should have gotten rid of the stuff sooner and updated others about the
change is not good.
6.1.2 a new t MUST be chosen, but is the interval not reset? Same in 6.1.3.
Hm, true. Any suggestions on better wording? Even the current one is bit
cumbersome, and repeating it twice with even more stuff in it is not
very appealing either.
Cheers,
-Markus
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
