|
![](/i/fill.gif) |
Darren New wrote:
> Patrick Elliott wrote:
>> This is not actually the case. Well, at least with Windows. For some
>> wacky reason, Windows handles "multiple" connections faster than a
>> single one. Don't ask me why..
>
> TCP Windowing perhaps. Lots of overhead in the kernel to turn around an
> ACK perhaps.
>
>> Oh, and that is one thing you can **not** do with FTP. FTP is blind to
>> how much bandwidth you use. It will use as much as it can, sans what
>> ever other processes are using.
>
> Well, technically, that's the client, not the protocol itself.
>
> The box I am programming for work, when you pick up the VOIP phone to
> make a call, it throttles back all the HTTP and FTP connections it's
> proxying, and then lets them go full speed again when you hang up.
>
Well, yeah. There are some managers that you can throttle as well, but
bittorrent I think works by knowing how much is coming in and going out,
and limiting it directly. In other words, it won't even *ask for* a new
fragment, if the fragment would exceed the cap. 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,
which is already sent, just that they didn't get their, and your FTP
software has to constantly check that what its getting doesn't exceed
the amount you set, and simply not send back an, "I got it.", message
when it wants to slow things down. This makes for a damned wobbly
limiter. lol
I haven't, myself, ever seen someone that actually limits what *other*
applications do use. Depending if it installs as a service, I suppose
there may be some way to manage that. Usually though, you can't set
bandwidth priority, and the default behavior is, "try to give all
clients equal capacity". Mind, the problem with an application that
*can* throttle everything else back is you run into the same issue.
Existing *standard* protocols do not have mechanisms to specify what
amount if bandwidth you have to work with, nor do they have a way to do
"fragment by fragment requests". This create the same jittery result as
a client based throttle, though, maybe not *quite* as bad, since you are
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. In some
cases, FTP in such situations will just time out, or drop connection, if
the server on the other end has issues, or poor settings. Having one
client "grab" all the bandwidth means you risk increasing the odds of
this kind of failure.
This is imho why I think for "data transfer", which doesn't require
streaming, we need to move to something like bittorrent for *all* of it.
The simple fact that you don't have to worry about dropped connections,
resuming issues, linear downloads, *or* trying to throttle bandwidth by
actually increasing the risk of time outs, failed connections and packet
loss, all make it vastly superior, even if it didn't have the p2p
aspect. FTP, no matter how you do it, risks all of the problems,
including making them worse, if something, intentionally or not, is
using your bandwidth.
--
void main () {
If Schrödingers_cat is alive or version > 98 {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
![](/i/fill.gif) |