Hi Folks, How to transplant X windows from machine to machine? Suppose I have a LAN of machines, each running various apps in different X windows and variously displaying on the local or on other machines (i.e. users have been logging in from various machines to various other machines). Now: a user, who has an app which is running on machine A and displaying on machine B, goes to machine C and wants to transplant the X window[s] from machine B so as to display on machine C, *without stopping and restarting the app on A*. The program 'xlsclients' can be used to find out the information which identifies X windows on the various machines. I guess that the X display an app appears on is "stored" in the running app itself (either picked up from the $DISPLAY for the session or set by "-display ... "), so that changing this involves sending some message to the app itself rather than to any X server. However, I don't have any idea how to send such a message (e.g. to a particular 'xterm' running on A and displaying on B, which is now wanted to display on C). Any ideas? Perhaps, as well as telling the app on A to change display to C, it may be necessary to tell the X server on B that it should stop trying to display the app; or maybe that may fall out automatically. (I guess process ownership issues don't pose a problem, since the user can log in to A or B from C as the user who owns the instance of the app). Just to make it clear: Initially, the user started the app on A while logged in from B. The user is now at C, and wants access to the app as if [s]he had logged in from C in the first place. Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <Ted.Harding@nessie.mcc.ac.uk> Fax-to-email: +44 (0)870 167 1972 Date: 24-Jan-02 Time: 08:42:05 ------------------------------ XFMail ------------------------------
On Thu, 24 Jan 2002 Ted.Harding@nessie.mcc.ac.uk wrote:
How to transplant X windows from machine to machine?
I'm fairly sure this can't be done in the way you describe, as disconnecting the display on "B" will result in the application believing it has no display, which would cause it to quit. One way I *have* done this in the past is with VNC. Run a VNC server on machine "A", and VNC viewers on "B" and "C". This means you are continuously running the application on machine "A" but you can look at it wherever you like. Ask google for more details on vnc/xvnc. Andrew. -- All views are my own .... who else would want them?
On 24-Jan-02 Andrew Savory wrote:
On Thu, 24 Jan 2002 Ted.Harding@nessie.mcc.ac.uk wrote:
How to transplant X windows from machine to machine?
I'm fairly sure this can't be done in the way you describe, as disconnecting the display on "B" will result in the application believing it has no display, which would cause it to quit.
Well, while I do strongly suspect that it can't be done, it's not for this reason. I reckon it's _logically_ perfectly possible; it's just that a comprehensive solution would probably be so complicated that no-one has implemented one. Consider how X works, taking the "xterm" app as a simple example. 1. User logs in to A from B and starts xterm at A. 2. xterm at A binary starts up, picks up $DISPLAY = B:0.0 3. xterm at A opens X connection to X server at B 4. xterm at A sends X requests to X server at B (please open a window, ..., please do the following in the window ... ); X server on B implements these. ... 5. User finishes with xterm and "closes" it from B; whereupon: 6. xterm at A requests X server at B to demolish display of xterm 7. xterm at A closes X connection with B 8. xterm at A exits Now suppose that, at 4 above, User moves from B to C, and logs in to A. Suppose User at C could: 5'. send a message to xterm at A which causes it to do the following: 6'. xterm at A requests X server at B to demolish display of xterm 7'. xterm at A closes X connection with B 2'. xterm picks up new $DISPLAY = C:0.0 3'. xterm at A opens X connection to X server at C Thereafter as at 4, 5, ... above with "C" in place of "B". There's nothing _logically_ impossible about this, and it entirely bypasses the problem you raise (that closing the xterm window in B pulls the chair from xterm at A), since it would be xterm which caused the window to be closed, and it would still be running and about to do something else (namely switch the session to a new window at C). However, this does depend on the existence of a mechanism for sending such a message. I'm pretty sure there's no such thing in X generally, though I can see how one might program a particular app to respond in this way if it received a certain interrupt. I suspect the reason it hasn't been implemented in X generally is that, while it looks simple in the above example, it ain't that simple for many apps. In particular, many apps spawn subsidiary apps which open their own windows, and which ... And some of these subsidiary windows might be displaying apps which have been started in other machines D, E, ... Unwinding that lot and switching it all to a new machine might be a tad tricky. Otherwise, it would be handy and entirely in keeping with X's "network transparent" philosophy (i.e. you can expect to work on any machine with apps running on any other machine as if all were taking place on the machine you are at), so you'd expect that the X people would have contemplated it. If, having contemplated it, they haven't done it, there is surely a reason ...
One way I *have* done this in the past is with VNC. Run a VNC server on machine "A", and VNC viewers on "B" and "C". This means you are continuously running the application on machine "A" but you can look at it wherever you like.
Thanks (also to Robert Tillyard) for this suggestion. I must admit I've contemplated getting to know VNC -- I have a friend who uses it happily in a mixed environment of Linux & Win machines. However, it involves much heavier load on the machines; the solution I was asking about would only involve a small overhead to do what is described at 6', 7', 2' and 3' above. But, while on VNC-like ideas: Another marvellous utility which I /have/ used is "xmx" ("X multiplexer"), though it's a good while since I picked it up -- I don't know whether it's still around, still less whether it has moved on. With this, you start xmx on A, and you can nominate any other machines on the network to be "guests"; and for each you can nominate whether it will have equal input rights to A, or none ("watch-only"), or "hand-up" rights (user at B can request input rights). Then an X window opens in A, and a mirror of it opens in all guests, within which is running an X session with its own WM (rather like xnest). Any machine with input rights can start new apps on A, whose windows appear on all guests. All machines with input rights have identical control over the apps (all running on A). So User_A moves his mouse -- all guests see the movement. User_B (with rights) moves his mouse -- ditto. User_C (with no rights) can only sit and watch. Keyboard input likewise. As you might guess, this was developed for classroom use in a teaching Lab of networked machines. While I've not used it for that purpose, I have used it with co-workers on other machines all working on the same project; this can be a, say, exciting experience. It gets even more exciting when you're all simultaneously editing the write-up. Unfortunately, it has some constraints on display parameters, in particular only 8bpp or 32bpp depth, and all machines must be running X at the same bpp depth. As it happens, my present setup does not lend itself to conveniently going along with that (I can only get 32bpp on one, and I certainly don't want to tie them all down to 8bpp). Anyway, an interesting area for discussion even if if didn't lead very far! Best wishes to all, Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <Ted.Harding@nessie.mcc.ac.uk> Fax-to-email: +44 (0)870 167 1972 Date: 24-Jan-02 Time: 19:11:02 ------------------------------ XFMail ------------------------------
On Thu, 24 Jan 2002 19:11:02 Ted Harding wrote:
Well, while I do strongly suspect that it can't be done, it's not for this reason.
I reckon it's _logically_ perfectly possible; it's just that a comprehensive solution would probably be so complicated that no-one has implemented one.
An X client (e.g. xterm) communicates with an X server (the thing that manages the display) by openning a socket to it. Any type of socket that supports reliable delivery of a data stream in order will do so as long as the server and Xlib have the code to support it. TCP and Unix Domain Sockets are common choices. There may also be a shared memory segment used for communication of some items if the client and server are running on the same machine. So, for a client to move from one display to another it would have to be instructed to close its socket connection to the first X server and open a new one to the second X server. In the normal course of events closing the connection to the old X server would destroy all the windows the client had so it would have to remember what windows it had up and re-create them on the new X server including all properies it had set on those windows. This is perfectly possible in theory, but current clients do not know how to do it. If such a facility were to be impemented the logical place to put it would be within the GUI toolkit (like Gtk or Qt) as it would be the job of each widget in the user interface to keep enough information to be able to re-create its window on a new X server. Steve.
Anyone know of something that will monitor bandwidth usage for an IP and give a basic stats page (Don't say ntop as its not really what i need) And split it down as in Mail 10 Gig WWW 2 Gig FTP 7 Gig etc... you get the idea... could really do with something like this Regards Darren
I think that VNC uses Xnest which allows a virtual display to be created without the need for a physical display, then when requests come in from viewiers it just allows them to see the display so the $DISPLAY that the xterm is running on will always stay constant. So if on hostA I'm running my normal X desktop the display is hostA:0.1 when I run xvncserver I can create a virtual display of hostA:1.0, if I use vncviewer on hostB the display that the xterm is in is still hostA:1.0. Rob. Steve Fosdick wrote:
On Thu, 24 Jan 2002 19:11:02 Ted Harding wrote:
Well, while I do strongly suspect that it can't be done, it's not for this reason.
I reckon it's _logically_ perfectly possible; it's just that a comprehensive solution would probably be so complicated that no-one has implemented one.
An X client (e.g. xterm) communicates with an X server (the thing that manages the display) by openning a socket to it. Any type of socket that supports reliable delivery of a data stream in order will do so as long as the server and Xlib have the code to support it. TCP and Unix Domain Sockets are common choices. There may also be a shared memory segment used for communication of some items if the client and server are running on the same machine.
So, for a client to move from one display to another it would have to be instructed to close its socket connection to the first X server and open a new one to the second X server. In the normal course of events closing the connection to the old X server would destroy all the windows the client had so it would have to remember what windows it had up and re-create them on the new X server including all properies it had set on those windows.
This is perfectly possible in theory, but current clients do not know how to do it. If such a facility were to be impemented the logical place to put it would be within the GUI toolkit (like Gtk or Qt) as it would be the job of each widget in the user interface to keep enough information to be able to re-create its window on a new X server.
Steve.
_______________________________________________ main@lists.alug.org.uk http://www.anglian.lug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
On Thu, Jan 24, 2002 at 08:42:05AM -0000, Ted Harding wrote:
Hi Folks,
How to transplant X windows from machine to machine?
I looked at this a few years ago. The only solution I could come up with was to have an X proxy in the middle which could accepts an X client then redirects outgoing messages to other X servers. This is what "xmove" does, there's a debian package for it. Package: xmove Priority: optional Section: x11 Installed-Size: 258 Maintainer: Adrian Bridgett <bridgett@debian.org> Architecture: i386 Version: 2.0beta2-3 Depends: libc6 (>= 2.2.2-2), xlibs (>= 4.0.1-11) Filename: pool/main/x/xmove/xmove_2.0beta2-3_i386.deb Size: 104796 MD5sum: a8a5b9c9c09b12980fdbfee24ebaa3ad Description: A Pseudoserver for moving programs between displays. xmove lets you change which display an X Window System program renders to - this could be a different monitor or even a different machine. -- pkl.net/~trj ..::::::::::::::::::::::::::::::::::::::::::::::::. /\_./o__ ....:::::::::' "Freedom defined is freedom denied." ':::: (/^/(_^~' ''::::: -The Illuminatus :::: ___.(_.)____ ':::::::::::::::::::::::::::::::::::::::::::::::::::
participants (6)
-
Andrew Savory -
D -
Robert Tillyard -
Steve Fosdick -
Ted.Harding＠nessie.mcc.ac.uk -
Toby Jaffey