[jdev] Re: XMPP Ping method?

[Artur Hefczyc]

Here is a discussion whether to use kind of Ping or Ack method
to make communication more reliable.

Let's define 2 terms:
Ping is a way to check whether other side is reachable where Ack
is a confirmation that some data has been successfully received.

Please note however that TCP is designed and implemented to
offer reliable and consistent communication between 2 end points.
So if you don't want to rely on TCP you have to basically reimplement
TCP mechanisms on application level protocol which makes application
level implementation very complex.
TCP was going to move that complexity away from application to make
possible implement "simple" protocols. So now we have FTP, HTTP, IMAP, 
XMPP and many others.

Unfortunately, for many reasons TCP is not as reliable as we would expect.
But in most cases it is reliable enough.

To decide whether we need additional level of protection depends on 
particular case and it is hard to set general requirements.
Let me explain it on 2 extreme examples:

1. Let's assume you want to have confirmation via XMPP of each
transaction made on your bank account. Usually in such case
you really mean to receive notification for each transaction even
though it is a few hours (or maybe even days) late. It is still useful.
And you even don't mind to receive some notifications twice.
You just need to receive all of them "at all costs". So implementing
kind of ACK confirmation with timeout does make sense and actually 
it might be enough protection.

2. Another sample case is, let's assume you read some sensors every
10 seconds (like CPU temperature) and send these data over internet
to XMPP client which checks the data and if values reach some level
generates alarm message. (like CPU overheating)
In such case you don't need any ACK, because sending side knows
it has to send data every 10sec and receiving side know it should receive
data every 10sec. So detecting communication error is very easy without
any additional mechanism. Furthermore you are not even interested in
resending data in case of communication error because in 10secods
data becomes outdated.

The point is that it is impossible to design/recommend a perfect
solution for all cases as many non-standard cases might have
different requirements. And for most standard cases we can
just rely on TCP layer.

Artur

On Wednesday 01 November 2006 19:45, Magnus Henoch wrote:
> "Michal 'vorner' Vaner" <michal.vaner at kdemail.net> writes:
> > Well, it is partly implementation problem, many OSes (as I heard) are
> > able to tell you how much was already delivered and if you remember what
> > part of data was what stanza, you can resend it after reconnection.
> >
> > But that is bit more work, of course, and alot more data.
>
> I'm in no way an expert in network programming, so what I'm about to
> write might qualify as disinformation; please write corrections or
> completions.
>
> We want to know if the remote side has ACKed receipt of all the bytes
> in a stanza.  In Linux, there is a way to get the size of the TCP send
> queue:
> https://www.jabber.org/standards-jig/2003-December/004570.html
> But it seems to me that using that method would be cumbersome:
>
> 1. Send stanza A to connection.  Save copy of A and size(A).
> 2. Prepare to send stanza B.  If send queue is 0, forget A and goto 1.
>    Else save B and size(B), and increase size(A) with size(B).
> 3. If send queue size is less than (the modified) size(A), consider A
>    to be acked.  Likewise for B.
> 4. If connection fails, queue or bounce all stanzas sent but not
>    acked.
>
> Or something like that.  I probably got it wrong somewhere, and I
> would probably make more errors if I tried to convert that into code.
>
> So it would be nice if sending a piece of data returned the sequence
> number of the last byte sent.  Then you could just compare it to the
> sequence number of the last byte ACKed, and then you immediately know
> if the stanza was received.
>
> Thus, we should try to convince makers of socket APIs to include
> functions to do just that.  Or did I miss anything?

-- 
Artur Hefczyc
http://www.tigase.org/
http://wttools.sf.net/