Files transfer protocol

[Archos]

Since the transfer of files is slow using HTTP (compared to FTP), is
going to be added any file transfer protocol at the Go library? FTP o
better any one based in UTP like

http://tsunami-udp.sourceforge.net/
http://www.tcnj.edu/~bush/uftp.html

[chris dollin]

On 8 March 2012 18:12, Archos <raul...@sent.com> wrote:
> Since the transfer of files is slow using HTTP (compared to FTP),

Is it?

Chris

--
Chris "allusive" Dollin

[Archos]

On Mar 8, 6:18 pm, chris dollin <ehog.he...@googlemail.com> wrote:

> On 8 March 2012 18:12, Archos <raul....@sent.com> wrote:
>
> > Since the transfer of files is slow using HTTP (compared to FTP),
>
> Is it?

At least for larger files, in change, HTTP is more efficient for
smaller files.

FTP was specifically developed to transfer files across networks. HTTP
trades off some features of FTP to improve transfer for smaller files
like web pages.

[Hotei]

I saw this on godashboard but I have no idea as to quality or currentness.

From the dashboard header : Go implementation of the bencoding protocol used by bittorrent

https://github.com/jsz/gorrent/tree/master/bencode

[Brad Fitzpatrick]

On Thu, Mar 8, 2012 at 10:12 AM, Archos <raul...@sent.com> wrote:

Since the transfer of files is slow using HTTP (compared to FTP),

This is simply not true.

In fact, HTTP is usually faster as it involves fewer round-trips.

[Archos]

On Mar 8, 7:43 pm, Brad Fitzpatrick <bradf...@golang.org> wrote:

> On Thu, Mar 8, 2012 at 10:12 AM, Archos <raul....@sent.com> wrote:
> > Since the transfer of files is slow using HTTP (compared to FTP),
>
> This is simply not true.
>
> In fact, HTTP is usually faster as it involves fewer round-trips.

That will be the theory because actually when I download some distro
from a FTP server, then the conection is always stable (it remains at
the same speed) and it takes lesser time than when I download it
through a HTTP server.

[Andrew Gerrand]

On 9 March 2012 09:08, Archos <raul...@sent.com> wrote:
> That will be the theory because actually when I download some distro
> from a FTP server, then the conection is always stable (it remains at
> the same speed) and it takes lesser time than when I download it
> through a HTTP server.

You say that, but I have had the reverse experience. Arguing with
anecdotal evidence gets us nowhere.

Brad is correct. FTP has significantly more complex set-up costs, but
once data is coming down the pipe both FTP and HTTP work in exactly
the same way. It's just a TCP connection.

Andrew

[Russ Cox]

On Thu, Mar 8, 2012 at 17:08, Archos <raul...@sent.com> wrote:
> That will be the theory because actually when I download some distro
> from a FTP server, then the conection is always stable (it remains at
> the same speed) and it takes lesser time than when I download it
> through a HTTP server.

In addition to all the other incorrect things about this that have
been pointed out, I will add that HTTP, in contrast to FTP, has
a way to restart a large transfer in the middle of a file if the
connection drops. FTP must start again from the beginning
of the transfer.

Russ

[Rodrigo Moraes]

On Mar 13, 9:37 am, Russ Cox wrote:
> In addition to all the other incorrect things about this that have
> been pointed out, I will add that HTTP, in contrast to FTP, has
> a way to restart a large transfer in the middle of a file if the
> connection drops.  FTP must start again from the beginning
> of the transfer.

Man, I haven't used FTP for a long time. But I remember that clients
had a resume feature that could be used if the server supported it.
Not the same thing?

-- rodrigo

[ziutek]

man ftp

reget remote-file [local-file]
Reget acts like get, except that if local-file exists
and is
smaller than remote-file, local-file is presumed to
be a
partially transferred copy of remote-file and the
transfer
is continued from the apparent point of failure. If
local-file does not exist ftp won't fetch the file.
This
command is useful when transferring very large files
over
networks that are prone to dropping connections.

[James McKaskill]

On Tue, Mar 13, 2012 at 08:37, Russ Cox <r...@golang.org> wrote:
> In addition to all the other incorrect things about this that have
> been pointed out, I will add that HTTP, in contrast to FTP, has
> a way to restart a large transfer in the middle of a file if the
> connection drops.  FTP must start again from the beginning
> of the transfer.

Most FTP servers support the REST command:

REST

Syntax: REST position
Sets the point at which a file transfer should start; useful for
resuming interrupted transfers. For nonstructured files, this is
simply a decimal number. This command must immediately precede a data
transfer command (RETR or STOR only); i.e. it must come after any PORT
or PASV command.

From http://www.nsftools.com/tips/RawFTP.htm

-- James