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