Hi Dan, On Tue, Feb 10, 2009 at 3:35 PM, Dan York <[email protected]> wrote: > > On Feb 10, 2009, at 7:18 AM, Victor Pascual Ávila wrote: > >>> DY> Perhaps this has been discussed a hundred times before and I've >>> missed >>> it... but doesn't allowing different DHTs to be used in RELOAD introduce >>> an >>> interop issue? i.e. Phones from Vendor A and Vendor B both nominally >>> support "P2PSIP" but turn out to not be able to interoperate because >>> their >>> *implementations* of P2PSIP use different DHT algorithms/protocols? >> >> Here I'd say: "Chord is mandated by default. If any other algorithm is >> used and you don't support it, act as a client" > > DY> Hmmmm... so a "client" doesn't need to know the DHT algorithm to join > the overlay network? Perhaps I just need more caffeine this morning, but I > guess I don't understand how any node can join the overlay network without > understanding the underlying algorithm. I understand that a "peer" would > need to know this to join in the overlay and the underlying DHT, but > wouldn't the client also?
See draft-pascual-p2psip-clients, Section 4, Argument number 4 http://tools.ietf.org/html/draft-pascual-p2psip-clients-01#page-6 Please, let me know your opinion. > >> Do you mean something like draft-jiang-p2psip-sep-01, section 6.1.1 >> >> http://tools.ietf.org/html/draft-jiang-p2psip-sep-01#section-6.1.1 > > > DY> Yes, exactly. > > DY> It would seem to me that if RELOAD is to support "pluggability" and > allow alternate DHT algorithms, it would need something like this to allow a > joining node to understand what underlying algorithm to use (and whether it > *can* join the overlay network). +1 Cheers, -- Victor Pascual Ávila _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
