[standards-jig] Improving network integrity
dizzyd at jabber.org
Fri Jan 2 05:45:35 UTC 2004
-----BEGIN PGP SIGNED MESSAGE-----
On Dec 31, 2003, at 5:12 PM, Robert Norris wrote:
> A stream feature seems like the wrong place for this - they're only
> really to add functionallity to a single stream, not to the network as
> whole. And there's no way to do end-to-end acks this way - there's no
> guarantee that two servers in the middle will set up acks (or even
> support them).
Agreed on both points. It's simply not practical for the current
Jabber/XMPP network to support hop-by-hop guarantees on delivery. It
would require a new network from the ground up with protocol
adjustments. This needs to be something done by the two endpoints
involved. That approach allows the current "unreliable" network to be
used and requires changes only in clients -- not it every server.
> You really need to set it up between the two endpoints (feels a little
> like esession to me). It might suck to have to do it every time.
One thought that crossed my mind when first reading this thread is that
we are starting to talk about defining a new layer in the Jabber
network. It is similar to esession, in that it requires both endpoints
to be carefully synchronized and follow very strict guidelines on how
they process messages. I'm not sure what this means long range, but it
seems like it could be a Big Deal...
> Maybe we could make it so that you request an ack on each packet you
> send, eg:
> <message to='foo at bar.com'>
> <ack xmlns='http://jabber.org/protocol/ack'/>
> Then the receiver knows it needs to ack. This doesn't help with clients
> that don't support it, but you'd have to deal with that anyway. And
> whether a client supports acks could be find via disco and/or caps.
> There'd need to be sequence numbers, timeouts, etc, and we'd need rules
> for an intermediate hop (eg s2s) to report a failure, but it seems this
> could work.
Yes, per packet ACKing is the simplest and quickest route to guaranteed
delivery. We could use a lot/most of the semantics from TCP. Of
course, this would _dramatically_ complicate clients -- but if you want
proper guaranteed delivery, that's the tradeoff.
All that said, i think overall it's not a bad thing to pursue
standardization of this.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----
More information about the Standards