help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improving tramp download speed


From: Kai Grossjohann
Subject: Re: Improving tramp download speed
Date: Fri, 20 Feb 2004 09:01:52 +0100
User-agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2 (gnu/linux)

fsu@sonnemans.net writes:

> I am currently using tramp to work with remote files. Using ftp
> transport tramp was fine, but I changed to scp transport for improved
> security and find that it is just to slow.
>
> What is the fastest way to work with remote files while still being
> relatively secure (no passwords in clear text acros the net).

One reason for scp to be slow is that it requires to set up a
connection every time when you transfer a file.  The file transfer
itself is fast, but this only pays off for large files.

I've started to use inline methods (ie, the method ssh instead of
scp), and I'm happy with its speed.  Even a fairly large text file got
transferred quickly enough.

With the ssh method, Tramp invokes mimencode (or a similar program) on
the remote end, then extracts the base64 encoded stuff from the shell
buffer (ie, the buffer *tramp/foo*), and base64-decodes the stuff
locally.  This means that there is some overhead, for the base64
encoded stuff is larger than the original file.  But Tramp doesn't
need to initiate another connection.

You could try to invoke scp manually to transfer a tiny file to get a
feeling for how long it takes to set up the connection.

Another possibility is to install the fsh package.  It's a program
(not an Emacs Lisp package) which multiplexes single ssh connections.
I gather that invoking fcp to copy files is also fast because fcp
knows to re-use an existing ssh connection.  I installed hooks for
fsh/fcp in Tramp ages ago, but I don't know whether they still work.

I don't know how the speed of fsh/fcp compares with just using an
inline method in Tramp.  Does anyone have experience regarding this?

Kai



reply via email to

[Prev in Thread] Current Thread [Next in Thread]