[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xougen] Re: [Xouvert-general] Network transparentcy and modules

From: Tyler Hall
Subject: Re: [xougen] Re: [Xouvert-general] Network transparentcy and modules
Date: Wed, 27 Aug 2003 01:39:06 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313

Andre Bender wrote:

Hash: SHA1

 >> G-LiTe / wrote:

Line72 wrote:

This is what I'd like to see.  There's no need to move the whole X
Session like you do with vnc, but it would be nice to be able to move
one window from display :0.0 to display :1.0, etc.

That might actually be harder than it sounds. Because there's a connection between the application and the X server, it's hard to just reroute that connection to the other server. This'd involve some extension on Xlib's side too. To move just any application you'd have to do this automatically in Xlib without the application having any control over it. (older applications are not aware of the extension and we still want to move those) There'd have to be some extension on the server side too ofcourse. I'm guessing there's a seperate application, like the window manager, that tells the application to move (actually talking to the extension on the X server) and the server then telling the Xlib part of that application that's about to move to disconnect and reconnect to another address.
Three problems I can think of right now:
- Where are we getting the addresses from? The window manager (in this case) would have to know what other X servers there are and where. - Would we allow the application itself to control (part) of this? Some Xlib functions for it? I have no idea. The way I explained it above it's handled fully in Xlib. - How are we going to redraw the contents on the other X server? Is it possible to just send an expose event for the entire window? Or would we have to resend the current state of the window? There's two ways to do the latter, entirely on Xlib's side or the X server extension contacts the other server (in which case the other server needs an extension for it too).

If there's an easier way, again, feel free to correct me. ;)

I've got a small issue left that hasn't been pointed out so far (or I overread it *s* ).

Someone mentioned he finds this feature useful to help his colleques to get a certain thing working. I agree totaly but this does mean both of them have to work as the same user logged into the system or else we do not only have to re-route the program but we also need to change the user id its running with. In the end, it seems to me a bit more complicated than some thought at the beginning. Of course maybe i've missed something, or got some strange thoughts. If so, please correct me.

so thats been my 2 cents


That also could tie in with another request mentioned earlier: allow multiple X users simultaneously on the same machine (ala winXP). The cross connections of "where can I move this window to" now could involve moving from User1 @ MachineA to User2 @ MachineB, or any other such combo.

In response to those questions above though, the window warp shouldn't have to break the X connection if the TCP connection has to be broken. The X protocol rides on top of TCP (or whatever base protocol you're using). A warp can be accomplished if Xlib sets up a 2nd TCP connection, this time to another X server (who thinks he is the only server displaying this window), then close the first TCP conneciton. You should even be able to implement an X-window client broadcast this way! The client (actually Xlib) could open many TCP connections to different X servers and wait for various DRAW commands from each server. Of course user interaction should only be allowed from one server at a time, the DRAW commands are a kind of read-only requests. Imagine a company message broadcast to all X-servers...nothing stops the user from closing or minimizing the window....but the message could be anything from a text message to a streaming video. I'm sure even online school courses could benefit from this broadcast feature...the core application doesn't need to know where all the DRAW requests are coming from, it would just think that the "single remote user" is rapidly hiding and unhiding various portions of the window.

I invision this example scenario for warping windows (from a purely user-friendly perspective, not trying to be ignorant of command line tools):

Say I have some future version of KDE/GNOME that supports window warping installed on machines A (my linux box in my office), B (my linux box in the lab down the hall), and Z (my headless linux box application server...not running X server).

I fire up machine A and log in as user1, telnet to machine Z and type something like:
  export address@hidden
signalling it to start an application and display it on "machine A, default display & screen on session owned by user1". This app asks the Xlib to open the connection, in the same way it has in the past before warping came to be. The Xlib will attempt various authentication schemes when connecting to machine-a as user1. Once authorized, the app will do it's normal thing and send the proper drawing instructions to machine A.

Now, for whatever reason I have to run down to the lab for an hour. While I'm there I realize I need access to the application already running on machine A. I go to machine B, log in as (or switch to) user1. I fire up my KDE/GNOME utility "grab window", and it can ask me for the target machine name (the one currently holding the window), or maybe it will do an X broadcast to search for valid X servers that will let me grab windows. To determine what to grab the utility connects to machine-A, authenticates me as user1, then queries the machine for all the windows it's currently hosting under sessions owned by user1, and asks the server to query each of those windows asking if it is capable of warping (ie. support the X11 warp extension). I am then presented with a list of warp-capable candidates, of which I can select one or all.

For each window I grab, machine A sends a message to the application (via the X warp externsion) telling it to go ahead and "warp" to machine B, giving it all the credentials it needs (infomation it received from machine B itself). The application (er, actually the Xlib) running on machine Z spawns a 2nd TCP session, this time it connects to machine B, and authenticates with it using the credentials it received from machine A. The application then sends a "success" message back to machine A and closes that TCP connection. Machine A tells my "grab window" utility about the success, and about the same time I'll see remote window show up on my session.

Phew, that's a long description, but it shows how possible this is. The only problem left to solve is: what would happen if machine A dies while I'm in the lab? Well, normally the application will shut down when the TCP connection is broken, but what if we change that behaviour? Instead, since this is all work done in the Xlib on machine Z, a closed TCP connection forces a "warp" to a local socket on machine Z. The application is put to sleep while the Xlib waits for a knight in shining armor to...well...to adopt it.

This could either be from a dedicated "warp server" daemon running on machine Z, that my "grab window" utility could connect to, or it could be a simple command line utility on machine Z that probes all open sockets owned by my application. Either way, once the socket is located, it is used to deliver the "warp request" message to the listening application. The application, again I mean Xlib, responds by opening the connection to machine B, authenticating, and then closing the socket! A lost X connection revived, Ta-Da!

All this work can be transparent to the application. X clients using Xlib don't know what machine they're displaying on do they? Why should they be informed that they were just warped somewhere?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]