Hi,
Draft-06 Section 9.4 is dated and needs work.
2. JP SHOULD use a series of Pings to populate its routing table.
3. JP SHOULD send Attach requests...
4. JP MUST enter all the peers it has contacted into its routing
table.
Section 11 provided a better method in which Attach requests are used
(instead of Ping) to discover and populate the routing table. There is
no need to use Ping. Suggest using the following text:
1. JP MUST connect to its chosen bootstrap node.
2. JP SHOULD send a series of Attach requests to discover and connect
to peers that make up its neighbor table as well as the desired 16
finger table entries. Note that this does not populate their
routing tables, but only their connection tables, so JP will not
get messages that it is expected to route to other nodes.
3. JP MUST enter all the peers it has contacted into its routing
table and connection table.
4. JP SHOULD send a Join to its immediate successor, the admitting
peer (AP) for Node-ID n. The AP sends the response to the Join.
5. AP MUST do a series of Store requests to JP to store the data
that JP will be responsible for.
6. AP MUST send JP an Update explicitly labeling JP as its
predecessor. At this point, JP is part of the ring and
responsible for a section of the overlay. AP can now forget any
data which is assigned to JP and not AP.
7. AP MUST send an Update to all of its neighbors with the new
values of its neighbor set (including JP).
8. JP SHOULD send Updates to all the peers in its routing table.
In order to populate its neighbor table, JP n sends an Attach via the
bootstrap node directed at Node-ID n+1 (directly after its own Node-ID).
This allows it to discover its own successor. Call that node s0. It
then sends an Attach (via the bootstap peer or s0) to s0+1 to discover
its second successor (s1). This process can be repeated to discover as
many successors as desired. The predecessors of JP will be found at a
later stage when JP receives an Update.
In order to set up its finger table entry i, JP simply sends an Attach
to peer (n+2^(numBitsInNodeId-i). This will be routed to a peer in
approximately the right location around the ring.
The joining peer MUST NOT send any Update message placing itself in
the overlay until it has successfully completed an Attach with each
peer that should be in its neighbor table.
Thanks
--Michael
Draft-06 Section 9.4 is dated and needs work.
2. JP SHOULD use a series of Pings to populate its routing table.
3. JP SHOULD send Attach requests...
4. JP MUST enter all the peers it has contacted into its routing
table.
Section 11 provided a better method in which Attach requests are used
(instead of Ping) to discover and populate the routing table. There is
no need to use Ping. Suggest using the following text:
1. JP MUST connect to its chosen bootstrap node.
2. JP SHOULD send a series of Attach requests to discover and connect
to peers that make up its neighbor table as well as the desired 16
finger table entries. Note that this does not populate their
routing tables, but only their connection tables, so JP will not
get messages that it is expected to route to other nodes.
3. JP MUST enter all the peers it has contacted into its routing
table and connection table.
4. JP SHOULD send a Join to its immediate successor, the admitting
peer (AP) for Node-ID n. The AP sends the response to the Join.
5. AP MUST do a series of Store requests to JP to store the data
that JP will be responsible for.
6. AP MUST send JP an Update explicitly labeling JP as its
predecessor. At this point, JP is part of the ring and
responsible for a section of the overlay. AP can now forget any
data which is assigned to JP and not AP.
7. AP MUST send an Update to all of its neighbors with the new
values of its neighbor set (including JP).
8. JP SHOULD send Updates to all the peers in its routing table.
In order to populate its neighbor table, JP n sends an Attach via the
bootstrap node directed at Node-ID n+1 (directly after its own Node-ID).
This allows it to discover its own successor. Call that node s0. It
then sends an Attach (via the bootstap peer or s0) to s0+1 to discover
its second successor (s1). This process can be repeated to discover as
many successors as desired. The predecessors of JP will be found at a
later stage when JP receives an Update.
In order to set up its finger table entry i, JP simply sends an Attach
to peer (n+2^(numBitsInNodeId-i). This will be routed to a peer in
approximately the right location around the ring.
The joining peer MUST NOT send any Update message placing itself in
the overlay until it has successfully completed an Attach with each
peer that should be in its neighbor table.
Thanks
--Michael
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
