On 2013-02-27 11:10 PM, ianG wrote: > Hi all, > > I'm wrestling with a protocol error condition where an action has been > done already, the requester innocently asks for it to be done, and is > told that it is already done. Idempotency, in a nutshell. > > The problem with "already done" in an idempotent sense is that it is > both an error and a success. > > Code-wise, it is hard to deal with quite so philosophically, it has to > fall as either an error or a success not both. > > Does anyone feel they've got a lock on which it should be? Or should I > implement a tri-state :( ? > > I'm currently tracing an instance of "create account" that is wending > its way up through layers of results, and it's getting a bit confused. > > Any message has a significant risk of being duplicated or lost.
Now when one has a single durable tcp connection, this possibility is supposed to be eliminated, at the cost of unpredictable delays and overheads, but the underlying unreliability shows through, as connections die and are restarted, or the impatient user hits the submit button twice. Thus one is apt to wind up implementing a second, badly done, reliability layer on top of the tcp reliability layer. If a second, why not a third? The second reliability layer emulates the impatient user, restarting failed or unreasonably delayed connections, and resending seemingly unacknowledged actions. Better to treat tcp as a way around packet size limits, and accept unreliability. If one gets a duplicate message, chances are that the acknowledgement one sent for the first message was not received, or has been unreasonably delayed. In which case, to prevent endless chaos, one should resend an acknowledgement that almost exactly duplicates the first acknowledgment. And similarly, if one gets a duplicate acknowledgement, silently ignore the second acknowledgment, or at most do something harmless, unobtrusive, and which does not result in any additional messages. _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
