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?
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).
Dan
--
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO Voxeo Corporation [email protected]
Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com
Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com
Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
