> Yeah, unfortunately, the growth is an issue and I don't think the above method > can be guaranteed to work. Short of the sending nodes being able to estimate > the size of the overlay and hence extrapolate the expected number of entries > in a via list and adjust the message size accordingly, we may have a problem.
IMHO, some statistics data from diagnostic procedure may be helpful for a sending node to estimate the possible hops for the request to be sent. For example, in Chord, the peer can periodically to send ping message to collect the hops needed to random keys which are located in difference scope in the circle. With this statistics data in mind, if a node wants to send a request keyed by key A, it can estimate the most accurate hops. More statistics data collected, more accurate number of the possible hops. OTOH, the peer also could record the maximum hop number, which is also be helpful to avoid future fragmentation. > Well, you are, however, potentially increasing the lookup latency. The via > list is probably the only reason that an intermediate node may be required to > fragment the message. An alternative might be for each node to maintain state > about the previous hop instead of including a via list. My concern about the state maintaining mechanism for symmetric recursive is still security issues. If a malicious peer controls a couple of peers, it can let peer A sends a great number of requests which is destined to peer B. Upon receiving the request, the peer B won't give the response intentionally. In this case, all intermediate peers are full of state which could be only be cleared by timeout, so that the overlay will experience the DoS. Am I missing something? _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
