On 11/3/2010 6:27 AM, Bruce Lowekamp wrote:
inline
On Tue, Nov 2, 2010 at 8:59 PM, Michael Chen<[email protected]> wrote:
Bruce,
As I said in the original post, the premise is JP uses the technique stated
in
Section 11 of the draft (and discussed in the thread titled "Clarification
of
initial attach procedure"), where JP did not PING and ATTACH to AP or NP
before
sending JOIN to AP.
I believe in the other thread, we concluded that Section 9.4 needs to
be revised to use Attach requests rather than Pings as currently
written. However, the example in Section 11 currently has JP sending
Attach requests to both AP and NP as well as its entire finger table
before sending the Join. Section 9.4, step 3 (of the current draft)
likewise has Attach requests being sent to the entire routing table
before the Join is sent. I don't believe there's a problem here.
Bruce
Thanks for explaining Section 9.4 and 11. The disparity in our implementation
is that JP does not ATTACH to NP, because NP will be in the UPDATE sent by AP
after accepting the JOIN from JP. Only then will JP actually ATTACH to NP.
Looks like this approach doesn't offer too much optimization compared to JP
ATTACH to NP before JOIN.
However, the race condition is still possible of NP just joint the overlay
right before JP sending JOIN, in which case both JP and NP will show up in
the UPDATE sent to them by AP.
Thanks
--Michael
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
