Red Hat X - Keeping the X session alive upon broken connection

Author

Keeping the X session alive upon broken connection

Andrei Alexandrescu (See Website For Email)

2005-03-02, 2:47 am

I am at the end of my wit after four crazy days of searching the net in
desperation.

(No, I am not Miriam Abacha and I don't want to transfer sixteen million
dollars into your account.)

After coming from the MS Windows connectivity world, where Remote
Desktop Connection allows me to remote only one entire desktop, I was
very pleased to see how my Linux machine is able to share either
separate windows or an entire desktop (or several of them!), in flexible
ways.

However, I was less than pleased when my connection broke and I noticed
that that meant instant death for *all* of my apps - the email I was
editing, emacs, everything! So I thought, I'm sure that's a common
problem that has been long solved. I first looked for a flag in the way
I start the server; then I looked for a utility; and before long, I was
desperately searching up and down the Net for a solution.

First, I was surprised that so few people have had this problem. I've
seen a few discussions on the Usenet about that, but not really like
"this is a known problem and here's how it's being fixed".

Second, I have found there are some solutions, none of which is entirely
satisfactory:

1. VNC server. The VNC server does exactly that - it creates a X server
on the remote machine, and then is able to share that for remote users.
When the remote user disconnects, the session stays there. So it's all
nice and dandy, but VNC has two problems compared to X:

a) It can't share individual windows, only full X desktops. Thus one
cannot use VNC-remoted windows managed on the user's machine.

b) It transports bits, not X commands, and as such it is slower
(transports the borders of all windows, the glyphs...) As such, X
transports less over the network because it stores (or caches) fonts
locally and it draws the borders on the user's machine.

2. xmove by Ethan Solomita.

http://public.planetmirror.com/pub/...0b2.README.html

This program is part of the Debian distribution, and it seems to be
awfully close to what I need to do. I even managed to compile it on my
Linux distribution. However, the lack of documentation and examples
makes it impossible for me to get my setup running.

3. XMX by John Bazik.

http://www.cs.brown.edu/software/xmx/

This is an X multiplexer that can do many thing, among which (I believe)
resumption of sessions after broken connections. I couldn't make that
work to save my life.

4. SCO XVision with the Vision Resume feature, which is supposed to do
exactly what I want. I downloaded a trial version and couldn't get their
Vision Resume feature to work on my Cygin/X server.

===============

So, could anyone help me with that? Any chance of a simple, sensible
program that allows me to keep my X-Windows session alive, but "grayed
out" when I disconnect, so it becomes fresh again when I connect again?

Thanks in advance,

Andrei

Scott Lurndal

2005-03-02, 6:07 pm

"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com> writes:
>I am at the end of my wit after four crazy days of searching the net in
>desperation.
>

>Second, I have found there are some solutions, none of which is entirely
>satisfactory:
>
>1. VNC server. The VNC server does exactly that - it creates a X server
>on the remote machine, and then is able to share that for remote users.
>When the remote user disconnects, the session stays there. So it's all
>nice and dandy, but VNC has two problems compared to X:
>
>a) It can't share individual windows, only full X desktops. Thus one
>cannot use VNC-remoted windows managed on the user's machine.

DAGS x11vnc. This will present your native desktop to a remote VNC
client.

scott

Andrei Alexandrescu (See Website For Email)

2005-03-04, 7:47 am

Scott Lurndal wrote:
> "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com> writes:
>
>
>
>
>
> DAGS x11vnc. This will present your native desktop to a remote VNC
> client.

Heh, interesting utility. But my need is to not export the desktop - be
it the native one or not - but to tunnel X connections over unreliable
networks.

Andrei

Scott Lurndal

2005-03-04, 5:58 pm

"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com> writes:
>Scott Lurndal wrote:
>
>Heh, interesting utility. But my need is to not export the desktop - be
>it the native one or not - but to tunnel X connections over unreliable
>networks.

Well this does do that (your X connection would be to the local desktop).
Loss of the VNC connection will not affect the X connection.

scott

>
>
>Andrei

Andrei Alexandrescu (See Website For Email)

2005-03-05, 7:47 am

>>Heh, interesting utility. But my need is to not export the desktop - be
>
>
> Well this does do that (your X connection would be to the local desktop).
> Loss of the VNC connection will not affect the X connection.

Oh ok ok. I misexplained this time around. I quote from my original
email why I would believe that forwarding the X traffic could be
preferrable instead of VNC:

===================================
VNC server. The VNC server does exactly that - it creates a X server on
the remote machine, and then is able to share that for remote users.
When the remote user disconnects, the session stays there. So it's all
nice and dandy, but VNC has two problems compared to X:

a) It can't share individual windows, only full X desktops. Thus one
cannot use VNC-remoted windows managed on the user's machine.

b) It transports bits, not X commands, and as such it is slower
(transports the borders of all windows, the glyphs...) As such, X
transports less over the network because it stores (or caches) fonts
locally and it draws the borders on the user's machine.
===================================

Now, I got word in private email that VNC is faster anyway because it
uses better compression. Would that be true?

Andrei