Hi,

Are ACKs exclusively for opening and closing TCP connections (I mean a
protocol ACK, not a application level ACK)?

When data is written to a TCP socket using write, the function returns
once the data has been copied to send buffer on the local machine.
When the data is received at the server, is a ACK sent back to the
client to indicate that the data was sucessfully received?

Thanks,
Aaron

In article <1163225704.236774.232110@k70g2000cwa.googlegroups .com>,
"Aaron" <odysseus183@hotmail.com> wrote:

> Hi,
>
> Are ACKs exclusively for opening and closing TCP connections (I mean a
> protocol ACK, not a application level ACK)?

No, they're also used to determine whether ordinary data packets have
been received. If no ACK is received by the sender, it retransmits the
data.

> When data is written to a TCP socket using write, the function returns
> once the data has been copied to send buffer on the local machine.
> When the data is received at the server, is a ACK sent back to the
> client to indicate that the data was sucessfully received?

Correct. The ACK is used almost exclusively to control retransmission,
it's not visible to the application.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barrry, thank you for responding.

I had one follow up question:

Even though these protocol (Transport layer??) ACKs are resolved
silently, are there any C functions that would allow the client to
"catch" the ACK returned from the data sent? For example, the client
would send the data and then this "ACK function" would block until it
received an ACK from the server. Or alternatively some sort of signal
that would do the equivalent?

The closest things I have found so far are
1. write the data and then immeadiately execute close with the
SO_LINGER option active (don't want to close the connection)
OR
2. program the client and server with application level ACKs
(redundant).

If possible I would like to find something better.

Thanks,
Aaron

Hi Aaron,

> Even though these protocol (Transport layer??) ACKs are resolved
> silently, are there any C functions that would allow the client to
> "catch" the ACK returned from the data sent? For example, the client
> would send the data and then this "ACK function" would block until it
> received an ACK from the server. Or alternatively some sort of signal
> that would do the equivalent?

the question you should ask yourself is: "why would be that piece of
information useful for my program"? What are you trying to achieve?
Usually, the causality property "if a process A sends message M1, and
then message M2 to process B, then process B receives first A and then
B" is enough to write distributed applications.

If you need a synchronization mechanism like "I want to continue if I
am sure that my application has received the message", then perhaps you
should look at RPC-like protocols (or more modern like RMI or CORBA).

To answer your question now, you could use libpcap to get a copy of the
packet received at the link layer, analyze it and find out if the
segment is a TCP segment with an ACK. Needless to say, it's far from
trivial... Some OS will give you the possibility to ask the driver via
ioctl(), or inspect relevant kernel information. But, obviously it is
system dependent.

Now, in the light of the previous explanations, if you still want to
stick to TCP, then the easiest/portable solution will likely consist to
build your own "synchronization" at the application level.

HTH,
Loic.