From the standpoint of the operator of the site providing the file, they care most about making the most money, or at least providing a service at minimal cost.
Which is somewhat obvious but drives tactics. Tactics are going to depend on how big a service they are. Someone operating a FTP server from a home Internet connection is a very different question to a big commercial service with many thousands or millions of customers. The latter is likely to run using something like Amazon’s large scale provisioning systems that dynamically scale with need.
A single ftp server will just give you the file as far as it can limited by the network interface it has. There will be a limited number of connections possible so it is better to get the transfer done quickly.
Scaling services will try to maximise the configuration and only call in new servers as needed. Scaling up costs more money. That may mean it is more cost effective to throttle bandwidth of downloads to stay within the currently provisioned connection.
Like I said above. There is science and art when provisioning at scale.
This is probably part of the disconnect from your end. It doesn’t really matter how the machines are networked, though that plays a part in some of the specifics.
Your connection could be computers connected via a network of ham radio towers. No really, ALOHANet used UHF as a primitive precursor to Wi-Fi to connect computers across Hawaiian islands and many of the issues you want to dismiss were literally the sorts of thorny issues and questions they had to deal with that were subsequently addressed with various protocols.
So, in a real world situation the same things mentioned above all apply. Unless you have a physical cable directly linking two machines (and even then…) all the network and protocol issues above are actually all directly related to a real-world answer.
As above, those are the parts that differentiate the real world cows from the spherical ones.
Basically, everything weve discussed is a valid approach - the server uses some algorithm to allocate bandwidth to the clients that demand it. how soon the server responds, and how much resources are allocated, depends on the strategy and so the algorithm the server chooses. Different companies, diferent files being served, available bandwidth, typical client capabilities, etc. - all determine the optimum strategy (in the eyes of the server owner). Also keep in mind customer perceptions are a factor in a business that serves files.
Here’s another example. I used to be a member of the Netflix rent-a-DVD imitator in Canada. With our excellent postal service, once a week to have them ship, me receive and watch, and send back - was about the freqency (bandwidth) of deliveries. I signed up fo some of the more popular new movies and a few obscure older movies from my childhood. While it was interesting to watch First Spaceship on Venus once again, I quickly realized that if I signed up for any golden oldie movies at all, they sent those instead of any popular movies, since - I presume - other customers only wanted current popular movies. So their algorithm delivered on time, but was a failure in delivering what I expected.
I think it was a matter of terminology. When “provider” and “bandwidth” start getting thrown around, people start thinking it’s a networking question.
What you’re talking about sounds more like some kind of server-side load balancing type activity. I’m not sure what the actual technical term for that is though.
FWIW, I think it was valid to question the concept of ‘connection time’. In a packet switched network, providers don’t care about connection time, because it isn’t really a thing; it’s just packets being exchanged; in one sense, you are ‘connected’ permanently, but it’s probably just as valid to say you are connecting and disconnecting multiple times per second. It’s been like this since dialup modems went away for most people.
The wires don’t care, true. But every network component operating at OSI Layer 4 or higher cares deeply about connections. A popular network attack took advantage of the fact that Connection-aware network elements (servers, firewalls, etc.) could be forced to crash by giving them pathologically too many connections to track.
Yes. Every download, as others mentioned very early, starts with an open connection, acknowledged, an entry in a table created for that connection. (DDoS attacks often seek to fill the table to its limit with bogus connections to prevent real customers getting access) Once a connection entry is created, then the task (download) starts and the computer puts the task in another table of tasks, where it tracks progress of requests. Then it closes the connection when complete, or if a timeout occurs, freeing up those table entries. So every individual connection takes a resource.
However, when starting the download, at the initial connection, the system has no indication how long this specific task will take. Even initial speed results may then fluctuate over time. The algorithm has to be adaptive. (Reminds me of an exercise in college, writing a scheduling algorithm for a job manager in an elementary OS. Each task is unpredictably long - do you increase or decrease priority of a task as it takes longer and longer?)
Also, you are presuming each download is a separate request and connection. Again, depends on the server and business.
Like everything in computers (and life) the answer is usually “it depends…”
Most TCP stacks support TCP Selective Acknowledgment (RFC 2018), so that a single missing packet in the middle of the window does not require retransmission of both the missing packet and all the following packets in the window that have already been received.