[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: >> G-LiTe /
Subject: Re: [xougen] Re: [Xouvert-general] Network transparentcy and modules
Date: Wed, 27 Aug 2003 12:48:01 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030818 Thunderbird/0.2a

Tyler Hall wrote:

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?


That is sortof what I was having in mind. It still doesn't really answer my questions though: - Where are we getting the addresses from? The gnome utility would have to know what X servers are running unless you want users to type in the address. - Would we allow the application itself to control (part) of this? Some Xlib functions for it?. 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) and sends a bitmap over.

> G-LiTe /

reply via email to

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