6481 10.4. Contacting a Bootstrap Node
6482
6483 In order to join the overlay, the joining peer MUST contact a
peer in
6484 the overlay. Typically this means contacting the bootstrap
nodes,
6485 since they are guaranteed to have public IP addresses (the
overlay
6486 configuration should not advertise them as bootstrap nodes
6487 otherwise). If the joining peer has cached a list of peers it
has
6488 previously been connected with in this overlay, as an
optimization it
6489 MAY attempt to use one or more of them as bootstrap nodes before
6490 falling back to the bootstrap nodes listed in the
configuration file.
Section 3.2 and 10.4 backs up my discussion. Technically speaking a
Client performs a bootstrap and when inside the ring will be
considered a Peer. So a Peer doesn't join the overlay as stated, a
Client does but more-so a Node in general. This could be more clear by
stating Node when referring to a Bootstrap or Join procedure instead
of a Peer on the Sender side. However in the end this is a "when are
you considered a peer vs client" scenario. For instance if you are
sending a Join chances are the intentions of the Node is to become a
Peer.
From 3.2:
1143 We use the term "peer" to identify a node in the overlay that
routes
1144 messages for nodes other than those to which it is directly
1145 connected.
This states that you are not not a Peer when you send a Join but
instead after the Join and Updates have been performed and the Node is
inside the ring. Therefore a Client or Node performs Bootstrap and
Join procedures not Peers.
Julian
On Oct 15, 2009, at 11:10 PM, jc wrote:
On what I just said. If Client A connects to Client B that is
connected to Peer Y then Client A can send a Lookup through Client B
to Peer Y performing the bootstrap. Should clients be able to
bootstrap off of other clients or is this to be reserved for public
ip addresses as currently stated in draft? The confusion of this was
created by multicast bootstrap. If multicast bootstrap is removed
then this won't be a problem anymore.
Julian
On Oct 15, 2009, at 10:36 PM, jc wrote:
Cullen,
I may not be on the same page as to what I just said.(old email)
This is referring to the fact that you CAN bootstrap off of ANY
node? If so then the terminology needs to state otherwise about
public ip address as well. Because you CAN bootstrap off of a
Client behind the same NAT that is connected to a remote Peer that
is inside the ring. I demonstrated this with multicast bootstrap.
If that is the case the following may be removed:
Because this is the first connection the peer
1461 makes, these nodes must have public IP addresses and
therefore can be
1462 connected to directly.
from svn:
1451 The first thing the peer needs to do is form a connection
to some
1460 "bootstrap node". Because this is the first connection the
peer
1461 makes, these nodes must have public IP addresses and
therefore can be
1462 connected to directly. Once a peer has connected to one or
more
1463 bootstrap nodes, it can form connections in the usual way
by routing
1464 Attach messages through the overlay to other nodes. Once a
peer has
1465 connected to the overlay for the first time, it can cache
the set of
1466 nodes it has connected to with public IP addresses for use
as future
1467 bootstrap nodes.
If this wasn't the topic please disregard.
Julian
On Oct 15, 2009, at 10:02 PM, jc wrote:
As long as a client can perform lookups on behalf of other nodes
this won't be a problem.
Julian
On Oct 15, 2009, at 9:06 PM, Cullen Jennings wrote:
I thought about this and talked to a few people. No one could see
any reason the bootstrap node had to be a peer (clearly it can be
a peer) so I went and updated the terminology to refer to
bootstrap node instead of peer. Folks on the list, think about
this one - if someone has a good reason that the bootstrap has to
be a peer, this will need to be changed back.
On Sep 10, 2009, at 4:54 AM, jc wrote:
Hi,
From subversion(04) draft:
3.5.2. Joining, Leaving, and Maintenance Overview
The first thing the peer needs to do is form a connection to
some "bootstrap node".
10.5. Contacting a Bootstrap Peer
When contacting a bootstrap peer, the joining peer sends a Ping
request to the bootstrap peer's known IP address with the
destination Node-ID set to the joining peer's Node-ID
When the requester peer finally does receive a response from
some responding peer, it can note the Node-ID in the response
and use this Node-ID to start sending requests to join the
Overlay Instance as described in
There are two problems here, the first is simply terminology.
3.5.2 uses "bootstrap node"
10.5 uses "bootstrap peer"
The second, 10.5 does not mention forming a connection and looks
as if it was based on a UDP bootstrap mechanism or the multicast
bootstrap(10.4). Am I correct that 10.5 is attempting to refer
to 3.5.2 and that 10.5 should clear up the fact that your
forming a connection to a bootstrap peer and not simply sending
a datagram to bootstrap nodes and waiting for responses?
REgaRDs,
Julian
_______________________________________________
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
