|
![](/i/fill.gif) |
Patrick Elliott wrote:
> In other words, it won't even *ask for* a new
> fragment, if the fragment would exceed the cap.
Yes.
> The ones that do
> throttle for FTP often take an, "its sending me stuff at Xkbs, so I need
> to ignore Y% of it." You haven't throttled anything, because the server
> on the other end has no idea *why* you keep requesting the same packets,
Uh, no. The client just stops reading from the kernel buffers, which fill
up, so the TCP window doesn't get opened up again, and the other side
doesn't get more buffer space to send into. When the client then reads 64K,
your TCP stack opens the window up by 64K, so the remote side sends 64K.
There's no need to request the same packets. Indeed, that would be a rather
asinine way of trying to limit how much data you're getting.
> and your FTP software has to constantly check that what its getting doesn't exceed
> the amount you set,
Errr, no. If you set your download to (say) 64K/second, your FTP client
reads 64K from the socket, then sleeps till the end of 1 second, then reads
another 64K, then sleeps again, etc. If it gets only 32K, it can either read
another 32K immediately, or wait for half a second, or whatever. The whole
TCP rate-limiting backpressure mechanism keeps the sender from sending
faster than it's being read at the client.
> and simply not send back an, "I got it.", message
That's exactly what TCP does, along with a "this is how much buffer space I
have for you to fill up now." It's just built into the TCP layer rather than
the application layer.
> This makes for a damned wobbly limiter.
It's the fact that it's going thru a number of layers that make it faster or
slower. It's wobbly with bittorrent too, because the requests have to go out
significantly before the data comes back. Just look at the bandwidth chart
on a client that gives you that. You're never going to get a constant rate.
The best you can do is a decent average over a fairly short time once the
stream hits a steady state.
> lol
You know, I'm constantly amazed at how amusing you find computers to be. :)
> I haven't, myself, ever seen someone that actually limits what *other*
> applications do use.
Sure. It's called QoS. Quality of Service. It has been built into IP since
the first versions. If you're using Windows, open up your network connection
properties and check "QoS Packet Scheduler" and bingo, you have something
that limits what applications use. The FTP client says "I want high
bandwidth and I don't care about latency" and the IM client says "I want low
latency and I don't care about bandwidth." And the routers in the middle
also deal with it.
It's also why you plug your VOIP box in front of your router instead of
behind it, for example.
> and the default behavior is, "try to give all clients equal capacity".
Not quite.
> Existing *standard* protocols do not have mechanisms to specify what
> amount if bandwidth you have to work with,
It's not up to the protocol, but the client. Welcome to the Internet. :-)
> nor do they have a way to do "fragment by fragment requests".
I don't know what this means.
> not limiting bandwidth in an efficient way, but instead relying on the
> other end to a) respond to requests to resend, b) resend at all.
No. Go read how TCP works. If you don't actually lose the packets in the
network, you don't have to resend any. There *are* fragment-by-fragment
requests. It's called the "TCP Window".
> cases, FTP in such situations will just time out, or drop connection, if
> the server on the other end has issues, or poor settings.
If the FTP server isn't feeding clients fast enough to keep them from timing
out, then you're just overloading your FTP server, yah. But if your
bittorrent server is overloaded, you'll also have clients going elsewhere to
get the file.
> The simple fact that you don't have to worry about dropped connections,
> resuming issues, linear downloads,
Bittorrent is a good download protocol, but HTTP has all that stuff too. The
advantage of bittorrent is being able to talk to multiple servers.
Anyway, it's not "streaming" that's the problem, but real-time delivery.
Neither bittorrent nor FTP handle "streaming" even if you have enough
bandwidth for real-time.
> *or* trying to throttle bandwidth by
> actually increasing the risk of time outs, failed connections and packet
> loss,
Throttling FTP traffic doesn't increase the risk of timeouts, failed
connections, or packet loss. The only risk of failed connections is that
connections take longer to finish, and thus stay open longer, so might use
up resources more. But that's like saying slow-eating restaurant patrons
increase the risk of slow food delivery - only in the sense that the people
outside the restaurant will be waiting longer.
> FTP, no matter how you do it, risks all of the problems,
Not really.
The only difference is that with bittorrent, the protocol is designed that
the only way to do a download is by requesting chunks. In FTP, being able to
restart a download, or take only the middle of a file, is an option.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
![](/i/fill.gif) |