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
