Forum Moderators: phranque
If not I would assume the server would send the file at a much higher rate and one of the hops would require some sort of caching...but that would make no sense to have computers intended to act only as internet cache. Then there is the issue of packet loss, and the client would send a signal to the server that a packet was lost and to resend thus slowing the overall speed of the transfer in general. So from that I can assume that in a dialup user's case their slow connection would be force set the maximum speed of all the signal. In a faster scenerio the issue might be a slow router in a nother state if you had one killer ISP or even the server to which you were connecting...so the slowest point of the packet's travels determines the maximum transfer speed I must assume?
- John
so the slowest point of the packet's travels determines the maximum transfer speed I must assume?
Errrr, no.
The maximum transfer speed is limited by a multitude of factors - generally, the main limitation is placed by your ISP, due to technological and other factors.
Then there's latency issues, hardware switching limits, bandwidth saturation etc.
There's normally some degree of buffering in routers. But generally not so much that it would represent a significant percentage of a file transfer.
TCP/IP is the basic streaming protocol that most higher-level Internet protocols (e.g. FTP, HTTP, SMTP, etc.) are based on. TCP/IP is designed to discover the optimum rate to send packets in order to avoid having them drop while maintaining maximum path speed. It's an end-to-end-protocol, so what's between really doesn't matter. (Note, though, that it's possible that routers in the middle might "snoop", and adjust themselves accordingly.) It's dynamic, so if one link along the path is slow for a while, and then fast for a while, you aren't penalized for the fact that it might have been slow when the connection was first made.
TCP/IP uses a "sliding window" algorithm, which allows a number of packets to be "sent ahead" without requiring immediate acknowledgement. Eventually, though, packets have to be acknowledged (or negative-acknowledged.) Once a sender has sent "n" packets, and there is no acknowledgement, the sender stops until there is one, and/or there is a timeout (in which case, it has to re-transmit). The size of the "window" (number of packets to send ahead) is variable and based on measured parameters.
The basic idea is to avoid flooding while at the same time trying to make sure a packet is always available when the reader is ready to read.
Define "speed". Each packet is typically sent at the maximum signalling rate of a particular link, interspersed, of course, with other, unrelated packets. So, if a link is 1gbit/sec, your file is sent on that link at 1gbit/sec. But if there's a 4K link somewhere, the packet rate is going to be throttled-back to avoid flooding the network with unacknowledged packets.