0

I heard, FTP is used to transfer files over a network. Also heard that it uses TCP port 20 and 21. So TCP is connection oriented. We have acknowledgments. If the transmission is lost, we should be able to continue it.

But my problem is, when we are downloading a file such as MP3, if the connection is lost, we need to download the file again. So then isn't it using the FTP protocol? Isn't it TCP? So if it is UDP, can you please explain what kind of protocol is that? TFTP ? I have no idea.

2

So TCP is connection oriented. We have acknowledgments. If the transmission is lost, we should be able to continue it.

"Connection oriented" does not automatically mean transfers using it can be resumed. "Connection oriented" simply means applications that use TCP can use it as a "pipe" - i.e. send messages of arbitrary length to the other side, and then TCP will make sure the message gets there (retransmitting if errors happen) in the same order it was sent. If a TCP connection times out because one side stops transmitting for whatever reason (i.e. they lost their Internet connection, crashed, etc.), a second TCP connection in and of itself doesn't necessarily know anything about the first one. The application software using TCP connections to transfer data on both sides would have to keep track of that and support that by starting a new connection.

But my problem is, when we are downloading a file such as MP3, if the connection is lost, we need to download the file again. So then isn't it using the FTP protocol?

I don't know why you are thinking that if something needs to be redownloaded that it must be using FTP. HTTP supports resuming interrupted downloads, but the server in addition to the client needs to support it. Not all clients and servers will support all features of all protocols at all times. HTTP for example - typically you can resume an interrupted download but some servers won't allow it.

Isn't it TCP? So if it is UDP, can you please explain what kind of protocol is that? TFTP ? I have no idea.

The fact that downloads can be resumed or not has nothing to do with identifying the protocol. There are many protocols that behave this way, and just because your download behaved this way doesn't mean a specific protocol was in use.

2
  • Thank You very much for explaining it briefly. I thought if a download stops after a crash, TCP will acknowledge that the packets didn't arrive at the destination and transfer missing packets again, so downloading will never stop. But now I know, that application/server does it. Thank You very much. :)
    – Zac
    Sep 5 '13 at 5:22
  • It will, but if it doesn't receive any reply to even the retransmitted packets (the limit of packets to keep "in flight" is controlled by the transmit window) it will eventually give up and assume the sender isn't there. The problem with depending on this to resume downloads is that you don't know if the sender has closed it or is still listening. So it's more reliable to just start a new TCP connection.
    – LawrenceC
    Sep 5 '13 at 17:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.