can TCP really guarantee delivery?

Question

I am reading a networking book and from what I have read about the TCP protocol, it makes sure the data will be sent. I want to write some code to do a file transfer. Before getting to that, I also read in the Python documents this passage:

"Applications are responsible for checking that all data has been sent; if only some of the data was transmitted, the application needs to attempt delivery of the remaining data"

This seems to contradict what I read in the networking book. The passage above says applications are responsible for the lost data.

I may be misunderstanding so I want to ask some questions:

1-If I have to check that the data is sent, then why use TCP?

2-I read in the networking book that TCP does the math to make sure that the data is there. Then why isn't using TCP a waste of time ?

3- The python docs didn't specify a buffer size. what is the maximum size of buffer to send at a time?

4-I read in the networking book that the server can increase the amount of data that it can send if it knows the client can receive it. can this change the size of the buffer more than the maximum number?

Here is my code attempt so far:

Server code:

import socket
s = socket.socket()
host =  socket.gethostname()
port =  3000
s.bind((host,port))
s.listen(1)
c,addr = s.accept()
with open("Filetosend","rb") as File:
    data=  File.read(1024)
    while data:
        c.send(data)
        data =  File.read(1024)
s.close()

Client code:

import socket
s= socket.socket()
host =  socket.gethostname()
port =  3000
s.connect((host,port))
with open("Filetowrite","wb") as File:
    data =  s.recv(1024)
    while data:
        File.write(data)
        data = s.recv(1024)
s.close()

Answer 1

TCP tries to guarantee that if the data is delivered, it's correct and in order. It uses checksums to ensure data isn't corrupted, and sequence numbers to ensure that data is delivered in order and with no gaps. And it uses acknowledgements so the sender will know that data has been received.

But suppose there's a network failure in the middle of a transmission. If it happens after the data segment is received, but before the acknowledgement is sent back, the sender will not know that the data was received. The sender will keep trying to resend the data, and will eventually time out and report an error to the application.

Most TCP APIs don't allow the application to find out precisely where in the communication the error happened. If you sent a megabyte, and get an error, it could have happened at the beginning, when hardly anything was sent, or at the end when most of the data was sent. It could even have happened after all the data was sent -- maybe just the last ACK was lost.

Furthermore, the write() system call generally just puts the data in a kernel buffer. It doesn't wait for the data to be sent to the network, and doesn't wait for the receiver to acknowledge it.

Even if you successfully close the connection, you can't be totally sure. When you close the connection, the sender sends a message to the recipient saying they're done sending data. But closing the connection just queues this in the network stack, it doesn't wait for the other system to acknowledge it.

This is why application protocols have their own level of acknowledgements, on top of the basic TCP protocol. For instance, in the SMTP protocol, the client sends the message contents, followed by a line with a . to indicate the end, then waits for the server to send back a response code that indicates that the message was received successfully and is being delivered or queued. TCP's checking ensures that if you receive this response, the message contents were sent intact.

Regarding the general ability of any protocol to guarantee perfect delivery of all messages, you should read about the Two Generals' Problem. No matter what you do, there's no way to verify delivery of all messages in any communication, because the only way to confirm that the last message was delivered is by sending another message in reply, and now that reply is the last message, and needs confirmation.