What is the purpose of Section 9.4 step 8, where AP sends an UPDATE to NP. Isn't that redundant since NP will receive the UPDATE sent from JP soon? If step 8 is eliminated, the race condition is avoided.
--Michael On 11/1/2010 6:57 AM, Bruce Lowekamp wrote:
I'm tempted to say it may be best to ignore this race condition---how much harm does it really cause to have two connections? To fix it, there's not only a race condition with simultaneous Attach, but also a possible case where one peer has detected a failure of the connection and tries to re-establish before the other realizes the connection has failed. Simply retaining the most recent connection to complete should work fine in all situations---there shouldn't be a circumstance where both peers do an immediate re-Attach, so if one accidentally drops the connection, it should reconnect on a timer. Another possibility would be implementing the connection table as a multi-map and limiting the number of entries per peer to two. That seems like a pretty effective way to deal with this without introducing too much additional complexity. Otherwise, I think the heuristic you propose is probably fine. Requires a bit more complexity in the implementation b/c you need to remember the transaction ID for each connection in the connection table, though I don't know if that's harder than other approaches. I think there would still be problems with one side noticing the failure before the other, but that's no worse (and rarer) than restricting to one connection. I'd prefer to leave this as an implementation detail, maybe with some text calling out the issue. Bruce On Mon, Nov 1, 2010 at 7:23 AM, Michael Chen<[email protected]> wrote:Hi, The scenario is a peer (JP) joins a ring of two peers: AP and NP, where AP is the admitting peer of JP. Referring to Section 9.4 of the base-11 draft, step 7, AP sends an UPDATE to JP, immediately followed by step 8, AP sends another UPDATE to NP. If JP uses the technique discussed in thread "Clarification of initial attach procedure" in which JP did not (or failed to) PING and ATTACH to NP before JOIN, then after step 8, both JP and NP could simultaneously send ATTACH to each other (via AP). It's possible that both JP and NP receive the ATTACH request from the other before receiving the reply to its own ATTACH request. The result is two ICE checks may commence independently and lead to in two TLS overlay links between JP and NP. JP NP --------- --------- ATTACH_r1 ----> <---- ATTACH_r2 ATTACH_a2 ----> <---- ATTACH_a1 ICE-1<---> <---> ICE-2 TLS-1<---> <---> TLS-2 Here is the problem. The draft does not define a heuristic to choose one ATTACH/ICE/TLS among the two and drop the other. For example, a simple one could be comparing the transaction ID of both ATTACH as an unsigned 64bit integer and drop the lesser one. Any opinions on this? Thanks --Michael _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
