[Standards-JIG] rfc3920bis: Stanza Acknowledgements
justin-keyword-jabber.093179 at affinix.com
Sun Nov 5 21:15:22 UTC 2006
On Sunday 05 November 2006 3:19 am, Bruce Fitzsimons wrote:
> Nice. It isn't made clear, but I think it is intended, that every hop
> can add/change/strip the ack status as it sees fit. So a non-supporting
> client doesn't stop the s2s connections from using it, and s2s will want
> to rewrite the sequence numbers
Yes, this is the intent, but you're right it isn't very clear.
> The way SCTP copes with this is to ignore the duplicates -- and I think
> XMPP can do the same. They're infrequent and the protocol overheard to
> try and avoid them is much more complicated than ignoring them. Think
> about all the extra permutations and the definition of behaviour for
> them...make it the client's responsibility to cope (display, suppress,
> whatever) not a protocol exchange with rules.
How do you ignore duplicates?
> I really can't see the need for "previous" requests.
The sequencing stuff is based on Dave Cridland's "mobile" scenarios. He wants
to have delivery tracking without acks. Simply tagging a stanza with a
sequence number adds no considerable overhead, but using round-trip acks do.
Sequence numbers are also useful for avoiding duplicate transmission, but I
don't think that was Dave's primary motivation.
The drawback to using sequence numbers is that you don't know which stanzas
failed to deliver until you reconnect. This means you need the ability to
reconnect, and you need to do it with the same client.
Personally, I think in a desktop IM client scenario, you would want to ack
every stanza immediately, and not bother with the sequence numbers. I'd much
rather have the client "bounce" my messages back to me as soon as it
considers the connection to be dead, than for me to wait an hour or a day
before I realize my messages didn't make it. Of course, only doing acks
means the client is really just guessing about what has been delivered, but
the problem window is very small, IMO. SMTP only uses acks, and dups are
However, I can see sequence numbers being useful in s2s, perhaps.
Reconnections should be easily possible, and they occur between the same
domains, so it would probably be effective.
Finally, it may be possible to combine both sequencing and acks, although I'm
not sure if that buys you anything.
> I'm wondering if you're solving the duplicates problem and another, that
> of how to relate the client queue to a newly opened stream? Shouldn't
> this be like queued messages are handled currently? It gets twisty when
> you're ack'ing message, presence and iq stanzas and the stream goes down
> though -- can we just write the message stanzas to storage and turf the
> rest? That would break the monotonous nature of the sequence
You can do this. :)
> I'm intrigued to know why you can turn on/off acking on a
> stanza-by-stanza basis. Some implementation notes around this would be
> useful -- are you thinking that a client may only apply this to messages
> and not to presence?
That's basically it. Messages are really the only stanzas that need acks for
error detection. However, acks can be useful for all stanzas as a
> 1. Um, I see an internal contradiction here. You say: "Acks SHOULD be
> sent as soon as possible, and MUST NOT be withheld for any condition
> other than a timeout.". Fair enough. But then your example shows the
> opposite behaviour to that which you've recommended? I'm confused.
Collecting stanzas "over a period of time" and a server "throttling stanzas"
are both time-based and should ultimately timeout. The idea here is that you
can't, for example, withhold acks because the other side hasn't yet sent a
message with "stop ignoring me" in the body. You can only withhold based on
time, and this time must expire without the sender having to know any trick
to get acks to work.
Do you have a suggestion about how to make this more clear?
> 2. Un-numbered acks are not a wise thing to include support for. If
> every message has one on, and you get many acks, where did you get up
> to? It becomes something like a heartbeat, it doesn't give any absolute
> message-by-message reliability, only a hand-waving "got to about here
> and it broke".
This is over TCP, so we don't need numbers.
> > 8. When a stanza is received, containing a 'c' attribute ("sequence
> > number"), the recipient SHOULD keep a record of this value as the
> > last received sequence number for the current stream. Everytime a new
> > sequence number is received, the previous number can be forgotten.
> I think you need a "monotonically increasing" requirement around here
> for the sequence number. Your design currently doesn't state that the
> client can't reuse them in other ways either.
Does this need to be a requirement? It is in the sender's best interest to
use a monotonically increasing counter, but since the recipient shouldn't
care either way, I didn't consider it a protocol issue. And since this is
not a requirement, reuse is sort of implied. But I can spell this out if you
think it is necessary.
> I'd like to promote the discussion that one ack can, and should, be able
> to ack multiple stanzas.
This is what the 'n' attribute is for, but maybe that's not what you're
> If we're really serious about XMPP over
> [anything] rather than assuming TCP then I'd like to remove the
> assumption I saw earlier today about stanzas on a stream arriving in
> order. They do on TCP, and some applications might want this behaviour,
> but is it a core XMPP requirement? Is a stream ordered? (RFC 3920 -
> "Definition of XML Stream" doesn't say so). Shoot me down please, it
> makes the implementation simpler -- but it should be more than implicit.
RFC 3920 defines the binding to TCP, and is ordered. The specification I've
proposed here is meant only for TCP. It would probably not be used in the
HTTP Binding, and an "SCTP Binding" would probably have a different
reliability mechanism, if it needs one at all.
Further, XML stanza processing is ordered. This is noted briefly in Section
10. By extension, I would assume that XML streams are also ordered (and,
well, they are, given that they are based on TCP).
More information about the Standards