[Top] [All Lists]

Re: [lemonade] update to RFC 1845 checkpoint/restart

2006-03-15 16:50:51

On Wed Mar 15 19:52:14 2006, Tony Finch wrote:
> > The REPLAY spec is currently weak in descibing the line between a retry > > and a replay. For example, the 555 response to MAIL would be better as a > > 455 that would cause the client to retry with a new transaction (i.e. a > > fresh <txn-id>). The corresponding situation with an improved CHUNKING > > would be an unexpected 355 response. The problem here is what happens if
> > the client has pipelined some data after the erroneous command?
> I don't follow all of this.

I'm worried about transaction ID collisions, which I suppose are most likely to be caused by a client going insane (unless someone manages to successfully attack a client's txn-id generation algorithm). At the moment the replay spec makes this problem detectable by the 555 response to MAIL (though I plan to change this to 455). Checkpoint assumes this situation is OK since it looks to the server like a normal transaction restart.

Right, gotcha.

You're saying that in the case where a transaction id collides, or, for some reason, the client thinks it's sending the transaction anew instead of resuming, then there's a problem here that 1845 missed because of the lack of pipelining.

A solution is to state that use of TRANSID= denotes either resumption or new, and the client must wait for the response unless it knows what it will be in advance (by having previously issued a REPLAY command and examined the response). Then add an additional parameter which indicates to the server that the TRANSID is expected to be fresh, and if not, to reject this transaction. (Perhaps a TRANSID-NEW assertion parameter)

This means that RFC1845bis (ie, this spec) clients use:

MAIL FROM:<foo(_at_)example(_dot_)org> TRANSID=xyz TRANSID-NEW

for starting a new transaction, and do not need to synchronize, whereas RFC1845 clients don't use the additional parameter, but do synchronize.

That handles the collision case, but the case where two clients simultaneously attempt to resume a TRANSID, is much more difficult to deal with.

You could define REPLAY as an assertion that subsequent usage of this TRANSID in a MAIL command in this session is a resumption, which prevents accidental duplication, and then you merely have to deal with failing DATA, BDAT, and BURL commands if a TRANSID is resumed by another session. (And, one assumes noting this in logs or to the sender as a possible bug or security issue.)

          You see things; and you say "Why?"
  But I dream things that never were; and I say "Why not?"
   - George Bernard Shaw

<Prev in Thread] Current Thread [Next in Thread>