[Standards-JIG] client-to-server and server-to-server connection failures cause silent message loss
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
2) Don't want to confirm message reciepts like with e-mail (see 1 befor
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
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:
Keep it simple... http://www.pavlix.net/
More information about the Standards