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" <[EMAIL PROTECTED]> 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: > http://mail.jabber.org/pipermail/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/
