[standards-jig] Improving network integrity

Dave Smith dizzyd at jabber.org
Fri Jan 2 05:45:35 UTC 2004

Hash: SHA1

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 
> a
> 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'>
>     <body>baz</body>
>     <ack xmlns='http://jabber.org/protocol/ack'/>
>   </message>
> 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.

Version: GnuPG v1.2.3 (Darwin)


More information about the Standards mailing list