[Standards-JIG] client-to-server and server-to-server connection failures cause silent message loss

Pavel Šimerda pavel.simerda.lists at centrum.cz
Fri Apr 28 20:35:21 UTC 2006


I am trying to reformulate it in a better way. Moving from "reliable delivery" 
topic is a must because most people expect 100% reliable delivery instead of 
improving network reliability.

Many people suggested that the only way is end-to-end message reciepts... I 
say, that message reciepts can be interesting. But they can't replace 
reliable connection. They can only be used if both sides agree to reveal 
their privacy and they are (at least now) useless for things like offline 
storage (yes, I know about AMP).

Simply.... I am one of the users that...
1) Don't want to reveal their privacy (e.g. difference between invisible and 
offline storage)
2) Don't want to confirm message reciepts like with e-mail (see 1 befor 
replying)
3) Don't want messages to be lost all the time even when I use solid client 
and server software... and loose them so often and everyday. (I have no need 
to have the other user confirm all my messages as it is with e2e reciepts).
4) I don't want to be seen online 15 minutes (or more) after I lose my 
connection. And I don't want my client app to tell me I am online when I'm 
not. I know... the tcp connection could recover... but for me it usually 
doesn't.

But... I also see it as a programmer...

The weak points are both c2s and s2s connections. The stanzas are lost "in 
between" because one point sends data and thus finishes its duty. That's bad, 
because it doesn't even check if it was transfered to the other point.

Tcp guarantees order but not completeness and some also suggested that you can 
recieve tcp acks from a router (not only from tcp destination). First, client 
software is responsible for message transport. Only when your server recieves 
the message, client should consider the message "on the way or already 
delivered". The same with s2s.

Then, if the remote client is connected... message should be delivered. If 
not, and the server supports it, it should be stored offline.

You never know if the message was delivered but at least we would get rid of 
almost all sorts of message losses. For me it seems natural to use message 
acknowledgements and connection pings as a solution.

I am aware that application errors can still cause message loss without any 
warnings. But I believe they are extremely rare (at least those you don't 
know about like server crashes and similar).

----

Jacek Konieczny wrote:
> So, that adds a meaning to otherwise meaningless whitespaces in XML
> stream. I don't like that idea. And how many stanzas are acknowledged by
> " \r\n"? What about implementations using whitespace for keepalives
> (sent even when no stanza was received)?  On the other side... such
> wacking would be much better when no link-level acking at all -- it
> could increase reliability in many cases.

I don't like that idea either. We're using a XML protocol and we should use 
ugly hacks to keep it together. If you believe XML is the way, then I suggest 
using it to it's full potential.

Message (and/or other) stanzas could be easily confirmed by a routing (or 
recieving) entity by an xml element. We can keep it very short or use 
confirmations/acks that apply to multiple stanzas at once. Pings are also 
very simple and efficient.

Again, good sources:
http://mailman.jabber.org/pipermail/standards-jig/2005-August/008260.html
http://delta.affinix.com/specs/xmppstream.html
http://mail.jabber.org/pipermail/standards-jig/2005-March/007174.html

Cheers, pavlix
-- 
Keep it simple... http://www.pavlix.net/



More information about the Standards mailing list