From: xscript@gmx.net (Lluís)
To: Ken Raeburn <raeburn@raeburn.org>
Cc: Emacs Developers <emacs-devel@gnu.org>
Subject: Re: Remote TCP server through ssh tunnel
Date: Mon, 25 Oct 2010 14:50:03 +0200 [thread overview]
Message-ID: <878w1m5tdw.fsf@ginnungagap.bsc.es> (raw)
In-Reply-To: <F46F8B21-586B-4D27-A543-2426C1510E88@raeburn.org> (Ken Raeburn's message of "Sun, 24 Oct 2010 17:50:31 -0400")
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 vilanova@gso.ac.upc.edu
>> # 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
next prev parent reply other threads:[~2010-10-25 12:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.LFD.1.10.0808311533530.2934@froglet.home.mavit.org.uk>
2008-08-31 18:22 ` Server port Stefan Monnier
[not found] ` <alpine.LFD.1.10.0808312118210.2934@froglet.home.mavit.org.uk>
2008-09-01 3:02 ` Stefan Monnier
2010-10-23 18:44 ` Peter Oliver
2010-10-23 19:29 ` Leo
2010-10-23 19:38 ` Juanma Barranquero
2010-10-23 20:01 ` Leo
2010-10-24 1:11 ` Stefan Monnier
2010-10-24 16:48 ` Remote TCP server through ssh tunnel [Was: Re: Server port] Lluís
2010-10-24 21:50 ` Ken Raeburn
2010-10-25 12:50 ` Lluís [this message]
2010-10-25 15:33 ` Remote TCP server through ssh tunnel Chad Brown
2010-10-25 16:28 ` Stefan Monnier
2010-10-25 17:28 ` Peter Oliver
2010-10-25 20:22 ` Lluís
2010-10-26 4:05 ` Ken Raeburn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878w1m5tdw.fsf@ginnungagap.bsc.es \
--to=xscript@gmx.net \
--cc=emacs-devel@gnu.org \
--cc=raeburn@raeburn.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).