Thanks for clarifying that, it got it now. But there's one thing for me to understand which hasn't been discussed here, yet:
There were several sentences in the draft letting me understand that the connection table (if using not compressed destination_type) has the key as the node_id, where i.e. when the peer gets a message etc. and has an entry in the connection table for that peer, it must forward directly (without consulting the routing table). I understand this (hope this understanding is right here). But imagine the initial case: Assume you have a bootstrap up and running and no other node, and a new node want to enter the overlay, let say as a client: 1. The new node gets the config document, now it is becoming very interesting: 2. It does a TLS connection to that bootstrap node. What now in detail ? Now it has to insert the connection information paired with the bootstrap node_id in its connection table (and also Routing table) before routing any _first_ RELOAD Message to a node over that bootstrap. More precise: It has now a connection and has to insert the connection information with the node_id of the bootstrap peer into the connection table. Does it learn the node_id for that connection from any information out of TLS ? Cheers, Frederic On Wed, Oct 27, 2010 at 12:14 AM, jc <[email protected]> wrote: > > On Oct 26, 2010, at 1:47 PM, Bruce Lowekamp <[email protected]> wrote: > > Yes, using PING first introduces some corner failure cases that simply > routing the ATTACH to the resource-id of JP does not. > > Section 9.5 doesn't actually conflict with the notion that the initial > attach is routed to the JP's resource-id, though. > > > 9.5 simply says that if peer A learns of peer B through peer C, it needs to > send the ATTACH through peer C. > > > This is a MUST or should be IMO. > > This is simply because A may not have connectivity with B other than > through peer C, such as when an overlay has been partitioned and is now > healing. The initial ATTACH is essentially handled the same way, because it > is routed via the BP. > > Bruce > > On Mon, Oct 25, 2010 at 6:56 PM, < <[email protected]> > [email protected]> wrote: > >> >> Yes, these methods are also ok. >> It appear to be inconsistent between section 9.5 and section 11. I think >> the method in section 11 is more efficient. >> >> >> >> >> *Frederic-Philippe Metz < <[email protected]> >> [email protected]>* >> 发件人: <[email protected]>[email protected] >> >> 2010-10-25 15:36 >> 收件人 >> <[email protected]>[email protected] >> 抄送 >> 主题 >> Re: [P2PSIP] 答复: Clarification of initial attach procedure >> >> >> >> >> Ok. So JP either can >> a) Send a ping to the resource id+1 (as the node_id of JP) to get the >> node-id (in the RELOAD message signature of the Ping answer) to then perform >> an attach to this node_id (this is mentioned in 9.4) or >> b) directly form a resource-id+1 (as JP's node_id) and send an attach. >> >> Do you agree ? >> >> Cheers, >> Frederic >> >> On Mon, Oct 25, 2010 at 9:04 AM, >> <*[email protected]*<[email protected]>> >> wrote: >> >> I think JP is correct. The Node of JP is as Resource-ID in Attach. Before >> Attaching, a Ping message is redundant. >> >> There is the description above the second dirgram in the draft: >> "It sends an Attach to the *Resource-IP* AP+1, which gets routed to NP." >> >> "Resource-IP" should be "Resource-ID". >> >> >> >> *Frederic-Philippe Metz >> <**[email protected]*<[email protected]> >> *>* >> 发件人: *[email protected]* <[email protected]> >> >> 2010-10-23 15:31 >> >> 收件人 >> *[email protected]* <[email protected]> >> 抄送 >> 主题 >> [P2PSIP] Clarification of initial attach procedure >> >> >> >> >> >> >> Hi all, >> >> I've got a question resp. page 123: >> >> The first attach in the call flow diagram states JP as the >> destination. I think it should be AP ? JP has got the node-id of AP >> from a previous ping, right ? If that assumption is not right, the >> attach to node-id JP will fail, because 5.5.1 states that the attach >> to a node-id which isn't reached will fail. >> >> Cheers, >> Frédéric >> _______________________________________________ >> P2PSIP mailing list* >> **[email protected]* <[email protected]>* >> **https://www.ietf.org/mailman/listinfo/p2psip*<https://www.ietf.org/mailman/listinfo/p2psip> >> >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail is >> solely property of the sender's organization. This mail communication is >> confidential. Recipients named above are obligated to maintain secrecy and >> are not permitted to disclose the contents of this communication to others. >> This email and any files transmitted with it are confidential and intended >> solely for the use of the individual or entity to whom they are addressed. >> If you have received this email in error please notify the originator of the >> message. Any views expressed in this message are those of the individual >> sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam >> system. >> >> _______________________________________________ >> P2PSIP mailing list >> <[email protected]>[email protected] >> <https://www.ietf.org/mailman/listinfo/p2psip> >> https://www.ietf.org/mailman/listinfo/p2psip >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail is >> solely property of the sender's organization. This mail communication is >> confidential. Recipients named above are obligated to maintain secrecy and >> are not permitted to disclose the contents of this communication to others. >> This email and any files transmitted with it are confidential and intended >> solely for the use of the individual or entity to whom they are addressed. >> If you have received this email in error please notify the originator of the >> message. Any views expressed in this message are those of the individual >> sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam system. >> >> >> _______________________________________________ >> P2PSIP mailing list >> <[email protected]>[email protected] >> <https://www.ietf.org/mailman/listinfo/p2psip> >> 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
