[Standards-JIG] Re: WHACK

Dave Cridland 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 
> too
> difficult to achieve. In general I tend to think that perfection is 
> not
> 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 
> last
> > dealt with from which session, and when a client connects and 
> explicitly
> > 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
> Binding:
> http://www.jabber.org/jeps/jep-0124.html#rids
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 
> are
> generated by the server. But we could have a protocol whereby the 
> client
> could request the last handled sequence number for its previous 
> session.
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 
> that
> > the stanzas are being dealt with in a timely fashion). 
> But on your model the client can get the same assurance simply by 
> asking
> the server for the sequence number of the last stanza it handled, 
> right?
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 
ping request.

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 
> extra
> > 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 mailing list