unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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



  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).