emacs-devel
[Top][All Lists]
Advanced

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

Re: Remote TCP server through ssh tunnel


From: Lluís
Subject: Re: Remote TCP server through ssh tunnel
Date: Mon, 25 Oct 2010 14:50:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Ken Raeburn writes:

> On Oct 24, 2010, at 12:48, Lluís wrote:
>> I've tried with this:
>> 
>> server$ emacs --daemon --eval '(setq server-use-tcp t server-host "0.0.0.0")'
>> server$ netstat -nap | grep emacs
>> tcp        0      0 0.0.0.0:13501           0.0.0.0:*               LISTEN   
>>    12078/emacs     
>> server$ ssh -R 13502:localhost:13501 firewall
>> client$ ssh -L 13501:localhost:13502 address@hidden
>> # I already have an existing tunnel for ssh connections to server
>> client$ scp server:.emacs.d/server/server /tmp/server
>> client$ sed -i -e s/0.0.0.0/127.0.0.1/ /tmp/server
>> client$ emacsclient -f /tmp/server -c
>> Waiting for Emacs...
>> *ERROR*: Display :0.0 can't be opened
>> [Exit 1 ]

> ":0.0" is the name you generally use for connecting to the local X11
> display on the machine running the X program.  That's what you've got
> on the client, and what emacsclient passes over to the emacs server
> process.  Unfortunately since that's running on a different machine,
> the local X display *there* -- if there even is one -- is not the one
> on your client machine.

Right. That's what I found out after trying it. The emacs server is
expecting everything to be run on the server machine.

What I expected was to run emacsclient as a sort of UI client
interacting with a remote server.

The objective is to have a local X window but doing everything on the
server. I know I could just "ssh -X" to the server and start a client
there, but insteractivity is too sloppy then due to network delay.

In any case, I suppose emacs is not ready for such a client-server
interaction, although I don't really know if that would be hard to
achieve.


> If your SSH path through is forwarding X11 as well as TCP connections,
> you need to find the server-side name for that forwarded "display" and
> give it to emacsclient to pass through.  I think that'll work; I
> haven't tried it.  (I usually just run emacsclient on the server
> machine, over an SSH session, and let it pop up a window over that
> same SSH session.)

That's what I do, but is not comfortable for high delay network
connections. As I said, I expected to run locally "as much as possible",
but modify everything remotely.

I suppose that's not an easy task, as emacs is still relying on a lot of
global variables, so client interaction still needs to send a lot of
information back and forth to the server.

This would probably require modifications to the core VM in order to
provide a true client-server model with client-side caching.


>> Do you have any clue of why is this happenning? According to the
>> documentation, this should work flawlessly (at least with hosts on the
>> same network):
>> http://www.gnu.org/software/emacs/manual/html_node/emacs/emacsclient-Options.html

> It's a bit misleading, yeah... evaluating an expression or editing a
> file in shared NFS space might make sense to trigger remotely like
> this, and the documentation was probably fine when multi-tty and
> daemon support hadn't come along, but now it probably needs to
> highlight these problems.

> Please file a bug report (M-x report-emacs-bug RET) and/or submit a fix...

You mean a bug report to the paragraph that misled me?


> (And of course the Emacs driving the new window will be running on the
> server, so it can't access files on the client machine without jumping
> through hoops.  If you really want to be able to do something on the
> local machine that triggers editing of files that are on the server
> machine, you might also look at the Tramp package, which will let you
> use your local Emacs, which may be faster.  But if you want to run
> subprocesses and such over there, or share an Emacs session there
> across multiple clients, yeah, getting a window popped up remotely may
> be best.)

As said, I did expect everything to run on the server, but without
sending "canvas diffs" of the X11 frames through the network.


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth



reply via email to

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