At Fri, 14 Nov 2008 01:04:28 -0800, Narayanan, Vidya wrote: > > > When an overlay is composed of heterogeneous nodes, it is > unrealistic to expect all nodes to have the ability to store and > serve all data
That's what being a node means in this context. If you can't meet the minimum requirements you shouldn't join the overlay as a peer, but rather as a client. > Now, a node may always reject the request to store > something. In a structured overlay, the particular set of nodes which are responsible for storing a given data object is defined by the topology. If nodes unilaterally refuse to store given kinds of data, this basically breaks the underlying semantics of the overlay, with the problem made worse by the fact that the overlay topology shifts over time. > It is not readily possible for a storing node to tell what type of > data it is being requested to store On the contrary: in RELOAD data is typed by "usage", so it is fairly clear. > - however, it may be reasonable > for overlays to have a guidance on the upper bound on the size of a > single data item. This should be configurable for overlays and may > even be advertised as part of the overlay configuration. This > allows participating nodes to be composed of heterogeneous > capabilities and still maintain a reasonable level of robustness in > the overlay. Nodes may choose to accept data items larger than this > upper bound - however, the data owner must be prepared for a > rejection of the store request when the data is larger than the > bound. > > Thoughts? We considered exactly this design during the early design phase of RELOAD. Unfortunately, it's unstable. The problem is that the set of nodes assigned to store a data value shifts over time. So, I may store value X with node A, which can accept it, but then node B takes over some of node A's space and node B can't store the data and it just silently vanishes. In order to provide any reasonable level of service expectation, the nodes have to be willing to provide more or less the same level of service as far as storage goes. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
