[ejabberd] ejabberd and reliable message delivery
flatworm at users.sourceforge.net
Wed Jun 4 19:38:09 MSD 2008
Teemu Harju wrote:
> Ok, Thanks for clarifying this for me. I kind of assumed that TCP ACKs would
> be enough for the server to notice that the message didn't go through. But
> thanks... I guess I'll use XEP-0184 then.
While many people (including me) think that there should be some
/required/ mechanism for transparent reliable transportation of
messages, TCP is completely out of place here because it just offers a
transport layer for XMPP: TCP ACKs acknowledge nothing more than ranges
of bytes in TCP streams. The TCP subsystem doesn't care about the
structure of the data it carries. So if we only rely on the TCP stack to
implement such "reception acknowledgement", the granularity of it will
be the whole TCP stream, i.e. a given TCP session either completes OK
(and then all the traffic was received by the remote) or ends with an
error (in which case we know not all the traffic was received, but
can't tell which part of it was, so we again have to use some
out-of-band way of synchronization after reconnect -- think of HTTP
partial transfers for instance).
P.S. Please respect the netiquette: delete irrelevant quoted text and
answer below quoting, not above.
More information about the ejabberd