> I think that clients will not be able to send operations back to the > server after the server rolls back unless we satisfy TP2. There is > always the chance that there are clients out there that have > operations that the server had once acknowledged but lost due to > rollback. When they reconnect days or weeks later, the server may not > be able to accept these missing deltas from the client because new > operations have been accepted by the server - accepting the deltas > would man that the client and server apply the operations in different > orders, leading to divergence in certain circumstances (note: TP2 > overcomes this divergence). The scary thing is that if I had done > work that causally depends on the operations that the server lost, I > won't be able to commit that work either. >
As long as the client does not discard sent deltas until it receives a commit notice, it will be able to resend those deltas. What's currently missing is a defined mecahnism for the client to know when it needs to resend deltas for which it had previously received a response, but for which it had not yet received a commit notice. Right now the only way for a client or wavelet remote to know that there is a problem is when it tries to submit a new delta after the host had crashed. If the submit response indicates that the delta is invalid then the client will have to "assume" that the host lost state and to resend all deltas it created after the last commit notice. I think it would make things cleaner if there was a specific error code indicating that the target version was invalid. Currently there is no way to be certain that it was the target version that was the problem. -Tad -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
