Re: apt: http vs. ftp?
the overhead of the second (data) connection is close to zero,
considering the size of data apt transfers. and you only need to make
additional connection once for all files from/to given host (that of
course depends on application, the web browser probably opens separate
connection for each file).
I am not sure about the data itself, there might be some error
detection there...
I still don't see how is http 'better' in all cases, and I am not sure
about speed as well...
erik
Harry Henry Gebel wrote:
>
> On Wed, Dec 06, 2000 at 10:53:57AM +1100, Chris Kenrick wrote:
> > Re: apt: http vs. ftp?
> > > Er, no it isn't. http is faster and better in all cases where there is not
> > > a proxy involved.
> > >> why would http be faster? how much faster you mean? and what makes it
> > >>better? AFAIK they are about equally good/fast for purpose of file
> > >>transfer...
> > Presumably the level of overhead that is added to the download by the
> > protocol
> > itself is less for http. This makes me curious .. why would a hypertext
> > transfer
> > protocol have less overhead on file transfers for one designed for
> > transferring
> > files?
>
> HTTP was designed for transfers of files where the requester already knew
> exactly what file he was looking for, whereas ftp was designed allow
> someone to poke around looking for a file or files he wants. So, it has to
> support to modes of operation, one a command-line-like mode and a file
> transfer mode. It opens multiple connection for the two modes, so depending
> on your client and server you can download (or upload) multiple files at
> the same time and still be poking around while that's going on. Plus, since
> FTP predates TCP/IP it may have error detection and correction builtin but
> it's been awhile since I read the RFC so I don't know for sure about
> that.
>
> All this capability (which is great in those situations where you need it)
> is overkill for many applications. An HTTP connection on the other hand is
> very simple, the client makes a request and the server makes a reply (well,
> it's a little more complicated than that, but not very). Usually that's the
> end of the matter although it is possible to send another request and get
> another reply, but I don't know how many clients actually support this. The
> name hypertext transfer protocol just comes from the fact that that was the
> first use of this particular protocol, but it is useful for an application
> like apt which also knows ahead of time exactly what files it is going to
> get and where they are located. Apt could get by with an even easier
> protocal since it never does anything at all except get files, but the
> difference would be so small that it wouldn't be worth not being able to
> use all of the existing http servers/clients that are already out their.
>
> --
> Harry Henry Gebel, ICQ# 76308382
> West Dover Hundred, Delaware
>
> --
> To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: