Friday, September 29, 2006

Cygwin and X Windows

Cygwin is a port of popular UNIX applications to Windows. Cygwin provides a UNIX like environment in Windows. Cygwin provides necessary UNIX System Call API allowing users to write and port UNIX based tools and applications by recompiling source code on Windows box.

Cygwin/X is a port of X Window System to Windows based on the Cygwin environment. Cygwin bundles Cygwin/X with its distribution. Cygwin/X allows users to run X Window server on there Windows machine which allows them to run graphical applications on a remote UNIX machine and display the GUI on the Windows box.

There are two ways to get the GUI from remote machines to Windows. First method is thought the use of DISPLAY environment variable and second using XDMCP. We shall see both the methods.

First things first, we have to see how to start our X Windows server. We have to start our X Window Server from the Cygwin terminal using the following command.

XWin –multiwindow –ac –clipboard > /dev/null 2> /dev/null &

So what does the above command do? It starts the X Window Server which can support multiple windows at a time. Remove access control on clients to connect to the server. Integrate with the windows Clipboard so that we can copy and paste between Windows and UNIX. Redirect the Standard Output and Error streams to “/dev/null” so that our terminal does not get cluttered with the debug information printed out by the X Window Server. And finally tell the shell to run this command in the background. Now we should have the X Windows icon in the Windows system tray. Set the Environment variable DISPLAY and run any X Window application like xclock, xcalc, etc. DISPLAY will in the format as follows


Display number will be typically being 0 (zero) until otherwise if you are running multiple X Window Servers on your windows box, same is the case of monitor number.

If you Bash use export and setenv for C Shell

$ export DISPLAY=


$ setenv DISPLAY

Run xclock as follows and we should get a our graphical clock as in the figure below

$ xclock &

Some thing like this should popup like this. Congrats you have successfully started your X Window Server and ran an X Window application locally. Now the next step is to do the same thing which running the application on a remote machine and getting the display on the Windows machine.
We can connect to a remote UNIX box using telnet, rlogin, etc, etc. Once we have successfully logged in then we can set the DISPLAY environment variable to point to your Windows box IP address. The DISPLAY environment variable is used to the X Window System to direct the GUI to the required machine. The target machine must be running an X Window Server as well. Only then the graphics sent from the remote machine can be captured and displayed on the target machine.
In the above example I telnet to a local UNIX Server and set my DISPLAY to my Windows Box and started a graphical text editor nedit. And I got the editor on my Windows Machine as shown below!

Now that you have seen the first method lets look at the problems that one might face. First and most common mistake is forgetting to set the DISPLAY environment variable or setting DISPLAY wrongly. The next problem might be that the firewall on your machine may block the incoming X Window message. The X Server will be listening to port 6000, check if that port is enabled on your machine.

We shall see what XDMCP can do it for us. First of all you don’t have to take the pain of connecting to a UNIX machine, setting the DISPLAY environment variable, XDMCP will do this for us. Let’s see what XDMCP is all about. XDMCP stands for X Display Manager Control Protocol. Using this protocol we can directly tell the X Window manager on the UNIX machine to forward all the graphics messages to our Windows machine directly.

To use XDMCP to connect to UNIX machine we have to do nothing special just add an extra argument while invoking X Server and remove one argument that’s all. We have to add the –query argument and remove –multiwindow argument and we are done. So our command line to invoke X Server will be

$ XWin –query hostname –clipboard –ac > /dev/null 2> /dev/null &

The –query argument tells the X Window Server to query the X Window Manager running on the remote host hostname to forward the X Window graphics to the machine from which you are querying. If the server agrees to this query then we shall get a graphical login screen.

Once you login, you shall be working on the remote machine itself in total Graphical User Interface. The display will be some thing like show in the screenshot below.

The troubles that we might encounter while using XDMCP is the remote machine may not be configured to respond to XDMCP query message. Secondly /etc/X11/xdm/Xaccess file on the remote host controls the access to XDMCP queries. Remote host Firewall might be configured to block query requests.

Links Cygwin Home page
Small intro on XDMCP
Linux How to, both holds good for most UNIX flavours.

Thursday, September 28, 2006

Virtual Network Neighbourhood


Can we think of a computing environment without sharing resources over a network? We might use FTP to transfer files from one machine to another machine or use Grid Computing to share processor time. Then our options of sharing resources with different platforms are very limited. The reasons for this big list of incompatibilities are different platforms use different architectures (x86, SPARC), protocols (NFS, CIFS), different byte orders (Little endian, Big endian) to list a few major restrictions.

The next question that we need to think is how to overcome this problem. Getting all the systems to use single processor architecture is not a viable option. The same with the byte order, but for the byte order we have a universally accepted Network Byte Order. Lastly the biggest hurdle, the protocol used to share the resource. One option is to use a common protocol among all environments. Once again this is not a good solution. The reasons being
1) Each type of resource needs to be shared differently
2) The semantics of one protocol doesn’t suit other environments.

Like a language translator can help us when we go a new country without knowing the native language, in the world of computer networks a “Protocol Translator” can rescue us from this situation. The Protocol translation is not a new concept it already exists in a different form at the lower levels of the protocol stack in the form of Gateways. If we could implement similar thing at the top of the protocol stack (Application Layer in OSI reference model) we can seamlessly share any kind of resource with any kind of computing environment.

Requirements of the Protocol Translator

Now that we have seen that a protocol translator can help us get out of this situation, we have to chalk out the requirements of this protocol translator.

i) Thin
ii) Handle different authentication protocols
iii) Serve multiple clients at the same time
iv) Stable

Requirement 1: Thin
The first point that we have to take into account is that to serve a single request from the client we will have to perform translation at least twice. Once from the incoming request to the target protocol and back again. But if the source protocol supports complex operations in a single request then we might have to perform multiple transactions with the destination protocol to achieve the required result. Hence we will have to keep the protocol translator as “Thin” as possible. If the protocol translator becomes “Thicker” then the response time takes a beating.

Requirement 2: Handle Different Authentication protocols
Every resource sharing protocol has its own system of authentication. Protocol translator should handle all these different Authentication protocols. Even after supporting all the different authentication systems we still have a problem. The authentication information given by the source protocol may not be suitable to use at the destination and vice versa. A good example is, CIFS (windows network neighbourhood) uses Challenge response authentication, but NFS (UNIX file sharing system) uses password authentication. In such a situation we have two viable solutions. First and the easiest way ignore the authentication which is not a good idea. The second is authenticating separately. That is we use the challenge response and authenticate the CIFS client and then when resource access is made we authenticate the translator with a predefined username and password with the NFS server. This is our best bet to ensure security.

Requirement 3: Serve multiple clients at the same time
The protocol translator must be able to serve multiple clients with different source and destination protocols at a given point. This way we can ensure transparency. For this requirement we can have a “Multithreaded” solution. A multithreaded solution will be light when compared to a “Multi process” solution. The reason being creating a process is costly (in terms of system resource) when compared to a thread.

Requirement 4: Stable
When we handle multiple protocols simultaneously we will have to be careful to mange the system resources used by the protocol translator. If the resources are not managed properly the translator might crash in the worst case or the response time will take a beating.