Score:1

Is it useless to reply the received messages (on TCP) on application layer to tell the sender the messages have been successfully received?

cn flag

Any data loss is detected and automatically corrected, which is why TCP is also called a reliable protocol.

In other words,

the transport layer is responsible for error-free, end-to-end delivery of data from the source host to the destination host.

TCP is guaranteed to be a reliable transmission indeed. A question is raised, is it redundant (or useless, sorry for my poor English) to reply the received messages (which are transported on TCP) on application layer to tell the sender that the messages have been successfully received?

ru flag
Consider an HTTP client sent a POST request to a server, will the client be happy if the server do not send back any response ?
John avatar
cn flag
@Chitholian Not a good example indeed.
Score:9
se flag

It is not redundant. TCP only cares about delivery between two systems, not between two applications. The ACK is sent once data are successfully received. The payload of the packets is then put into the socket buffer of the application on the receiver side. The ACK is thus send before the application has read the payload (from the socket buffer) and specifically before it processed the payload, for example made changes to a database based on the processed payload.

Thus a client can only know that the applications has successfully processed the payload, if it gets some kind of acknowledgement at the application level. This does not need to be an explicit acknowledgement though - simply sending a response back might be sufficient. Details depend on the semantics of the application protocol.

John avatar
cn flag
I fully understand and agree that "the ACK is sent once data are successfully received". But why do you mean by "put into the applications socket buffer. "? As far as I know, the ACKs could **not** be known by the applications **indeed**!
Steffen Ullrich avatar
se flag
@John: TCP is commonly handled by the OS kernel. From the application side there is the socket where reading and writing is possible. If data are received by the kernel they get put into a memory buffer associated with the buffer - the read buffer. A later read from the application will simply retrieve the data from this read buffer. In case of a blocking read (i.e. application waiting for data) the data will be put into the read buffer by the kernel and then the blocked application will be woken up so that it can read the data from the buffer.
John avatar
cn flag
I see. You mean the data **other than** ACK is put into the buffer which will be read by the application later. Thank you for your clarification.
Steffen Ullrich avatar
se flag
@John: Yes, I did not consider ACK to be *data*. These are just transport information. I made it more clear now by talking about the *payload* instead.
John avatar
cn flag
I see, thank you so much.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.