Hi Pekka,
I think this would work even in the case when the responses are crossing. Let each device send its response irrespective of whether it itself has just sent the request. Irrespective of who sent/received the response first, if we sync to the higher values, then eventually both the devices will end up having same values. In the approach which I suggested, B need not wait for A to respond. It can just send its values and ignore (don't update the received values ) the message response received from A Please correct me if I am missing something. While arbitration can also be used, the above approach seems simple. Regards, Kalyani -----Original Message----- From: Pekka Riikonen [mailto:[email protected]] Sent: Thursday, September 16, 2010 3:14 PM To: Kalyani Garigipati (kagarigi) Cc: Yaron Sheffer; IPsecme WG Subject: RE: [IPsec] Moving forward with the HA solution draft On Thu, 16 Sep 2010, Kalyani Garigipati (kagarigi) wrote: : Regarding the race condition, I think instead of starting the message : Id's altogether with 1, we can have the devices sync up to the higher : value among the responses. : : Cluster A Cluster B : request SYNC --> : <-- request SYNC : response (4,4) --> : <-- response (5,5) : : Cluster A should update its values to 5,5 whereas Cluster B should not : update its values since its values are higher than the values at Cluster : A. : Which means Cluster B has correctly synced its message values to some : extent when compared with Cluster A. : I don't think this can work, because the responses can cross each other in the network also, and most likely do if the requests did as well. That is, Cluster A responds same time as Cluster B before it has received the response. The implementation would have to wait for the response before sending its own response. But, what if the other end is waiting it also? It's a dead lock. I think it needs to be a pre-defined value that both end set in this case or there needs to be some arbitration between the peers to deicde who waits. I'd go for the simplest solution. Pekka
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
