At Tue, 24 Mar 2009 18:21:09 -0700, Narayanan, Vidya wrote: > > Based on section 9.4, successor replication is already supported in RELOAD. > However, the following sentence makes it unsuitable for a generic targeted > STORE request, such as would be needed for caching: > > "The peers receiving these check they came from an > appropriate predecessor in their neighbor table and that they are in > a range that this predecessor is responsible for, and then they store > the data." > > I am not sure that the above check really buys much anyway. So, perhaps we > can do without it. Any node may reject a STORE request that it is unable to > honor anyway.
Hmm... I don't think this is true. If a node receives a STORE request which it is supposed to honor (i.e., it's responsible for the resource-id) and the request is otherwise valid, it must process it and store the data. If it is unable to do so for some reason (e.g., it's out of disk space), then it needs to exit the overlay. Otherwise, we've created a condition where the overlay can be permanently unreliable. The converse of this is that nodes need to know which requests they are required to honor. > Also, I notice that section 9 is a little light on normative text. It > probably needs a further scrub to ensure it is implementable in an > interoperable fashion. Specific comments are welcome here. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
