Hi Bruce, You said " A client doesn't need to know anything about the overlay algorithm". Does it mean client node can not even run the Hash for resource ID for itself? If so, almost all the functionalities of the reload are realized by peers. Only the unified Node_ID connects the clients and peers topologically in a same overlay level. However, even this kind of topology relationship is not stable considering the unreachability of a client to its responsible peer caused by client mobility or something else (That's the reason that, I think, reload base has the second option for client routing in section 3.2.1). I totally agree to allocate Node_ID for clients to give them a status for communication with peers at overlay layer level. But besides this, I do not think there is necessary to integrate client protocol into peer protocol, considering the different behavior of them. It could make such an all-in-one protocol too complex. So, I still think separated description for peers and clients could make things more clear. : )
Best Regards, Xiao Lin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ext Bruce Lowekamp Sent: Wednesday, February 11, 2009 12:51 AM To: Dan York Cc: [email protected] Subject: Re: [P2PSIP] Interoperability vs Pluggability (was Re: mobile p2pin p2psip) On Tue, Feb 10, 2009 at 10:06 AM, Dan York <[email protected]> wrote: > Victor, > > On Feb 10, 2009, at 9:58 AM, Victor Pascual Ávila wrote: >> >>> DY> Hmmmm... so a "client" doesn't need to know the DHT algorithm to >>> DY> 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. > > DY> Ah... so the clients communicate with the P2P overlay "peer" nodes > DY> by > way of the "client protocol". So if the P2P overlay supports such a > client protocol, client nodes can connect to the overlay without any > knowledge of the underlying DHT algorithm (or anything else in the > underlying overlay network). > > DY> Got it... thanks for explaining. > > DY> This does, of course, assume that whatever P2PSIP protocol we use > DY> would > have a client protocol. > Clients are an integral part of the current reload protocol. This is already there without a need for a separate client protocol. A client doesn't need to know anything about the overlay algorithm, it just sets the destination in the via list and lets the peer it's connected to figure out to get it there. http://www.p2psip.org/drafts/draft-ietf-p2psip-base-01a.html#anchor11 Bruce > Regards, > 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 > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
