[Standards-JIG] rfc3920bis: Stanza Acknowledgements
justin-keyword-jabber.093179 at affinix.com
Wed Nov 8 22:06:34 UTC 2006
On Monday 06 November 2006 4:07 pm, Bruce Fitzsimons wrote:
> Having sequence numbers progress in an orderly fashion also helps
> efficient implementation -- if every id is just an opaque tag then you
> have to linearly search your sending queue to find the matching start
> point. The potential for duplicates also creeps in fairly easily if
> people pluck them from undefined places, you end up needing another
> requirement saying "don't duplicate id's within <criteria> time". The
> criteria involves a time envelope including both sender and reciever so
> it is a bit hard to define programmatically.
In the original proposed text, an opaque tag would be enough because only the
last received value would matter. It would not have to be a number, because
the recipient of the value wouldn't be comparing it to greater or lesser
values. In fact, it wouldn't even compare it to anything. There's no linear
searching whatsoever. There is simply just one stored value, which is
divulged to the peer, when the peer asks for it.
That said, in the newer ideas from my last mail, where unsolicited acks
respond to sequence numbers, the value certainly does need to be an
> >> 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.
> > <snip>
> > Do you have a suggestion about how to make this more clear?
> Ok. I think Dave Cridland has provided an excellent response, although
> I'd like to make the timers shorter. I think we're all agreeing that a
> one-ack for many packet model is the scalable way to go though. We're
> just debating how explicit we need to be about what we're acking, and
> how often that needs to be :-)
I disagree with having explicit timeout values regarding acking. As I wrote
in my other message, acking could be something you wait for indefinitely.
I can understand why people may want to be disconnected sooner, such that
presence is more properly reflected. It sucks to send a message to someone
you think is online, when they are not really online at all. However, the
greater problem, IMO, is the fact that the message might go into a black
hole. At least with acks, we won't lose anything, even if the other person
doesn't fall offline until a 20-minute TCP retransmission timeout.
> I'm intrigued by your argument that heartbeat/ping is different to
> reliable delivery. This is just so different from other protocols I'm
> familiar with that have them interlinked (including TCP, SCTP, SMPP, EMI
> and internal protocols). Heartbeats are fill-ins for when there is
> insufficient real data to validate the connectivity in these protocols.
> It comes back to the discussion of TCP connections vs XMPP streams --
> are pings checking the heath of the TCP connection while acks
> potentially cross multiple TCP connections without concern?
This isn't TCP vs XMPP, but "health of the stream" vs "what has been
accepted." This difference is really only important if we consider server
The throttling problem first occurred to me when I was working with XEP-47
(Inband Bytestreams). The problem is that there is no mechanism for
flow-control between the client and the server, and so it is difficult to
decide just how fast you should send the data packets. As it stands now, you
either send too fast and get penalized, or send slowly (with a hard-coded
sleep value) which is suboptimal.
I figured one good solution to this, if we had stanza acks, would be for the
server to withhold an ack if the client is sending too fast. This way, the
client can send as fast as allowed by the server, simply by waiting for an
ack before sending the next packet.
This is probably all fine and good for everyone, but where it gets tricky is
when you consider the downright harsh penalties that are in some servers.
With jabberd, you could be penalized on the order of minutes. If a client
has a 30 second ack timeout, there's trouble. We either needs acks to be
sent immediately, even if the client is being penalized (which means
flow-control is completely lost, and the client is in the dark again), or we
need a separate mechanism for doing timeouts.
I don't mean to make a false dilemma out of this; there are other
alternatives, like using sane throttling values, or ditching throttling
More information about the Standards