|
![](/i/fill.gif) |
Darren New wrote:
>> 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.
>
Going to shorten this and just say that, what you describe is
interesting, but not what you "see" as a layman, actually having to deal
with the result. I couldn't care less, for example, if HTTP has a mess
of things in it, it **still** can't deal with a server that runs into a
serious enough problem that it needs to restart. As for FTP resumes,
that only works of the damn server supports them. Ironically, half the
"big" companies on the net disable it, so you end up starting at the
"first" block of the file, every time you resume. Restart on those is
"literally" restart. And I won't even get into the numerous idiot things
they do on web sites, which are intended to do everything from make
download managers harder to use, verify who is downloading, etc., which
can do anything from making "all" downloads from the site impossible, if
you are not using "generic" in-browser support, and no plugins at all,
to causing it to refuse you, because the "client" you have making the DL
request doesn't match the client that initiated the link to download it.
Mind, all that later stuff is pure nonsense with the web design and the
lack of any "consistent" way to prevent a) multiple connections via FTP,
when that is the intent of all the hoops you jump through, or b) what
ever else they are trying to do.
All I know is, FTP is the least reliable way I know of, without a
manager that is *far* more robust than either the one in IE, or Firefox,
or *any* other browser I have ever used, and HTTP isn't much better, in
"some" cases. :( We need something where the fact that the server is
overloaded doesn't mean a) having to come back and retry 3 hours later,
when you might be at work (or every day, in hopes the load drops), or b)
your 5 hour (or worse 5 day, if you have a slow connection), download
isn't going to fail 50 minutes in, every single time, FTP/HTTP or what
ever, and the server won't resume where it left off. Oh.. And the one
**big** issue imho.. If you have glitchy wiring, or other issues,
FTP/HTTP can land you "bad" files, and short of running an hash on it,
which only some sites even provide (as a separate download), you have no
damn way of knowing if the 4GB ISO you downloaded, or the 6GB of game
files, or what ever, "got" to your machine intact. Nothing like trying
to download the same installer 10 times, and having it fail with, "This
executable is either corrupt or the wrong format", every single time,
each time an hour download. What little error correction exists in FTP
and HTTP is in the packet level, and it simply *doesn't work* well
enough to be certain that the file will arrive intact, when it seems to
work at all.
Like I said, unless you need a streaming protocol, there are "huge"
issues with FTP *and* HTTP, when it comes to having them be both certain
to be reliable and certain to complete. That the torrent might go
looking some place else, if the main source fails is beside the point.
It *can*. The closest to that *at all* for FTP/HTTP is some things like
Getright's support of "search known download sites for a link to the
same named file", which is worthless if its not *actually* the same
file, or version.
--
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) |