[Standards-JIG] Synchronization points
dave at cridland.net
Mon May 1 13:15:58 UTC 2006
On Mon May 1 11:12:59 2006, Bruce Campbell wrote:
> On Tue, 25 Apr 2006, Dave Cridland wrote:
>> An alternative would be to introduce synchronization points, such
>> that the server would inform the connecting client what the
>> previously know synchronization point was on connect. (I'm
>> assuming that whitespace pings or some other NOOP will handle
>> detecting whether a suspiciously silent connection is actually
>> The simplest thing would be to add in an integer attribute on
>> potentially every top-level element, such that a client simply
>> grabs a new one (strictly increasing allocation), and can then
>> know easily what was and wasn't received by the server.
> With the idea that older clients will just ignore the 'sync'
> attribute on all top-level elements as per 'if you don't recognise
> it, ignore it'? It'd work, but there are two issues with it:
Well, I was assuming this would be a negotiated stream feature, so
there's no idea of sending extra attributes anyway.
> Either it is hop-by-hop, or end-to-end. It cannot be both without
> introducing two seperate attributes.
end-to-end is a different issue, and a much more complex one. Besides
which, you need hop-by-hop reliability to get end-to-end receipts and
disposition notifications to work reliably anyway. So while I agree
with the point, I don't think it's an issue against this proposal,
nor any other hop-by-hop reliability mechanism.
> Long-term, busy connections will be hit with a subtle increase in
> traffic size (a problem with introducing any new attribute to
> all/most stanzas).
Yes, but by increasing each stanza marginally, it's a lot less than
increasing the number of stanzas, and worse, packets, which the ACK
proposals are doing. So yes, it's certainly increasing data transfer,
but by less than the alternative proposals.
In real figures, using a sequence number means an addition of around
18 octets max per stanza - 10 for the number, 2 for quotes, 1 for
'=', and 5 for a three-octet attribute and a one-octet namespace
prefix. This could be elided by assuming that the current sequence
value was simply the count of all stanzas, but I suspect it's easier
to have it explicit. (It saves rules for dealing with TLS and SASL
For any ACK-every-stanza mechanism, you're generally going to add
34-40 octets for the extra packet headers, before the ACK stanza
itself. So whether this is a whack or a stanza-ack doesn't matter a
great deal, it's still going to cost double.
> Rather than a seperate integer attribute on every top-level
> element, why not (ab)use the '<presence/>' element for this
> purpose? I mean, define a 'sync' type which otherwise does not
> change the 'online' status, use the existing 'from' and 'to'
> attributes to determine whether it is hop-by-hop or end-to-end,
> re-use the 'id' field to provide a count of stanzas sent in total,
> and add 'sent' and 'last' attributes for timestamping, eg:
> <presence type="sync" from="thisendhop" to="otherendhop"
> id="COUNT" sent="JTIME" last="JTIME"/>
Okay, leaving out the discussion of whether using <presence/> stanzas
for this is a good idea (I would have thought that <message/> or an
entirely new stanza might be better):
1) There's no point in sending the count. By the time the receiver
gets the stanza, it knows the count - TCP does that much reliability
2) What are sent/last? I'm probably missing something, but I assumed
the intent was to send "sent" as the current time, and "last" as when
the last sync stanza was received, but that doesn't make sense when I
stopped to think about it.
> Done as a stream feature that connections opt-into, it can be used
> as both hop-by-hop and end-to-end, and only increases traffic to
> the tune of two extra stanzas every X minutes (one each direction).
No, it can't be done end-to-end, can it? I didn't think there was any
method by which one endpoint could know how many stanzas had been
transmitted to another in the other's current session. I can envisage
servers performing presence damping, for instance, and even without
that, I don't think it's possible, because of <presence/> and sync
stanzas crossing on the wire.
> Note that this would simply provide detection of missing stanzas.
> What clients do with the knowledge is a seperate issue.
Not for hop-by-hop, it isn't. For hop-by-hop, when you know that
stanzas are not getting through, it's "drop the TCP connection,
reconnect, resend stanzas that weren't received. If reconnection
fails, notify the user". Whichever mechanism people go for, it's the
same post-fail activity.
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