[TriLUG] X remotely --- was 'Screen for X?'

Owen Berry trilugbucket at berrybunch.net
Tue Sep 23 13:46:45 EDT 2003


After a little reading and experimentation it appears that the only
reason the application was still running on machine A was that the ssh
connection had not yet timed out, and since the X connection was being
forwarded over the ssh connection the client didn't know that it had
been disconnected from the X server. Once the ssh connection timed out
and died the client died with a socket error. This is all quite logical
now that I think about it and I guess the way to go when dealing with
flaky connections is to use something like VNC.

BTW, I tried the VNC module for X from http://xf4vnc.sourceforge.net/
and it seems to work well with good performance. Thanks for the
references on that.

-- Owen

On Mon, 2003-09-22 at 15:03, Owen Berry wrote:
> Thanks for all the feedback on that question - definitely helps. One
> more question on this topic, although it is more straight X related:
> 
> Say I have machine A and machine B on my local network. I am sitting at
> machine B and start a GUI application on machine A using ssh and
> forwarding X traffic. The application happens to be an editor of some
> kind, which I use to make some changes to a document. Suddenly the
> network connection on machine B dies briefly (wireless), losing the
> connection to machine A and also losing sight of the editor. When I
> reconnect to machine A via ssh I can see that the editor is still
> running, but I cannot interact with it and ensure that I save my changes
> before killing the process. Any way around this problem? Can I reconnect
> to the client in some way?
> 
> I mostly use vi for editing so I don't often have this problem, but
> occasionally the need arises. Since X was designed to work across
> networks in this manner, it seems crazy that a flaky network connection
> could cause such a problem, unless the user is just ignorant. :-)
> 
> Thanks.
> 
> -- Owen
> 
> On Mon, 2003-09-22 at 09:50, H Brett Bolen wrote:
> > this is x0rfbserver.  you can find it on the net.  It uses your :0
> > display.  It is somewhat costly to run -- it slows down your
> > host processor because it is using XGetImage and computing the changed
> > sub images manually.  The diff computation takes alot of cycles.  The
> > good news is that it uses standared X calls so it should work on
> > any x server.
> > 
> > there is also a project that adds this to xfree86.  It is named xf4vnc --
> > check sourceforge.  You copy some files to xfree86, and it exports
> > your :0 display without extra programs.  This is much faster because
> > it is integrated int the X server, which knows where the diffs are.
> > 
> > Basically you add some share libs to xf4vnc, updated the XFCofngi-4 file
> > and poof, you have access to your :0 host screen.
> > 
> > I use both x0rfbserver and xf4vnc with x2vnc to simulate a dual headded
> > workstation ( NT on left, linux on right).
> > 
> > 
> > 
> > Ken Mink wrote:
> > 
> > > KDE3.1 and up has their remote desktop feature. This is basically VNC at
> > > the window manager level, I think I've got that right. Anyway, if you
> > > enable remote connections on your existing session, you can attach using
> > > the KDE remote desktop client. I leave myself logged in at home and
> > > tunnel back in from work all the time. The nice thing is that you don't
> > > have to start the VNC server on a separate display to use it.
> > > It is not per application as the original poster requested, but it does
> > > allow reconnecting when desired. Since it is based on VNC, you can use
> > > the client to connect to standard VNC servers as well.
> > > 
> > > Ken
> > > 
> > 
> > 
> > -- 
> > b²
> > 
> > -----------------------
> > -- H Brett Bolen
> > -- TCNi
> > -- Phone: 919 550-0828
> > -- eFax : 509 752-8446




More information about the TriLUG mailing list