[Standards-JIG] Re: WHACK
dave at cridland.net
Wed Apr 26 22:33:40 UTC 2006
On Wed Apr 26 20:28:15 2006, Peter Saint-Andre wrote:
> Dave Cridland wrote:
> Slightly less unreliable
> messaging might be enough for most people. 100% reliability may be
> difficult to achieve. In general I tend to think that perfection is
> an option.
Best is the enemy of good. Yes.
My model certainly isn't perfect - for instance, if the dead session
times out, and the receiver forgets about it before the sender can
reconnect, then it's still unknown whether the last stanzas need
resending or not. In its defense, this would need to be around 20
minutes at least, by which point the messages may not be valid
anymore, and the user certainly needs to be notified.
> > And it's possible to get actual reliability, and - I think -
> quite easy.
> You mean 100% reliability?
No. If I could think up a way of getting to 100%, I would, but
generally it involves infinite timeouts, perfectly behaved software,
and everlasting batteries, I suspect. The latter two would be good
things to have anyway, it's the infinite timeouts that have me
stumped without using infinite memory, which in turn requires a CPU
capable of addressing an infinite amount of memory. Of course, that's
leaving aside user mortality problems.
Seriously, by reliability, I really mean that the user is generally
not even aware there was a problem unless it's quite serious, in
which case the message may be lost or duplicated.
> > You just add an optional sequence number to each stanza, specific
> to a
> > session, and the server keeps a note of what sequence number was
> > dealt with from which session, and when a client connects and
> > requests that session identifier again, the server tells the
> client what
> > it last dealt with.
> This sounds quite similar to the Request IDs that we use in the HTTP
I think that's similar, yes, except of course that the nature of HTTP
means that you always have the ACK.
> In XMPP, session identifiers are not requested by the client, they
> generated by the server. But we could have a protocol whereby the
> could request the last handled sequence number for its previous
Ah, I thought the session identifiers could be requested by the
client as well, similar to resource identifiers, for some reason.
However, I think (hope?) that's a detail. If not, we just add that
mechanism. (We might be able to use resources, but I'm not quite so
sure about that.)
> > You can add an iq to get an explicit ack if you like, but it's not
> > terribly important unless a series of large stanzas have just been
> > transmitted by the client, in which case it might want to know
> when it
> > can forget them. (It's also important if you need some assurance
> > the stanzas are being dealt with in a timely fashion).
> But on your model the client can get the same assurance simply by
> the server for the sequence number of the last stanza it handled,
Sort of, but it's more interesting than that. The other end-point
could return an error on that request - it'd provide the same
information. Really, it could be a NOOP or echo command and have the
same information. All you're looking for is a reaction to a datum at
a specific point in the stream. This is more of a ping than an ACK,
almost, but it also indicates acceptance of the stanzas prior to the
Note that this isn't really about processing, it's about acceptance
of the responsibility of the stanzas' processing. This is wildly
different to an end to end receipt mechanism.
> > If you use these,
> > you're actually getting ACKs, but if you don't, you're getting no
> > packets, but yet you still get better reliability than a dumb ACK.
> The "no extra packets" part seems pretty important on the kinds of
> unreliable links that people are complaining about (GPRS etc.).
On some of them. A NAT on a LAN is somewhat different, since the data
overhead and even packet overhead isn't as important, but keeping the
connection live is. GPRS is also NAT, generally, so you still need to
keep the connection live, but my model is divorcing, to an extent,
the keep-alive function from the reliability function, and in any
case, you only need to send a single packet in one direction to keep
a NAT connection live, so whitespace padding on an idle connection
would seem the best choice here.
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw
More information about the Standards