One thing that should have been obvious from the examples above is that, in X, you are sending a lot more than just plain text from the remote machine to your local PC. Graphics will require a lot more bytes than text, and it takes time to transmit those bytes. Even “plain text” may require a lot more time than it would in an ordinary telnet session. To send a line of text under X, the remote machine may need to send information on what font to render the text in, and may in some cases even need to send the font itself to your PC.

If even ordinary telnet connections seem slow to you, you have real difficulties running X. Nonetheless, you can't expect to get by transfoerring only plain text in all circumstnaces, so trying to work out a connection scheme that you can live with is important.

When we talk about connection speed to the internet, most internet service providers (ISPs) only talk about how many bytes per second they can ship to you. For web browsing and email, that may be the most important factor. But programming activities tend to be highly interactive. Even in a telnet session, you type a command, you pause to see it echoed on your screen so you can make sure it's what you wanted, you hit the Enter or Return key, you wait for a result to appear on your screen, then you start typing the next command.

For our purposes, then, what's important is not only the bandwidth, the number of characters per second that can flow along a connection once the data stream has gotten started, but also the latency, the amount of time it takes for the last byte of a request to go from your machine the remote machine and, assuming the remote machine responds immediately, for the first byte of its response to reach you.

When X is displaying something complicated on your screen, there's a lot of back-and-forth communication. That means that latency is at least as important as bandwidth in determining how well X will work for you.

Ideally, you would have an ISP that gives you both high bandwidth and low latency. Most cable services and DSL will give you that. Dial-up services are fairly low bandwidth, but the better ones offer very low latency and so may be OK with X.

Beware of "satellite broadband" ISPs. These bounce their data streams off a satellite in orbit. Even at the speed of light, this adds a lot of time to the delivery of each byte. Satellite broadband can offer high bandwidth, which is good, but they also frequently have very high latency. Even telnet can be painful on a satellite broadband service. You hit Enter and wait.... Satellite broadband may be fine for web browsing and email - once the data stream gets going it just flies. But some programming students find they are better off doing dial-up because of the latency issues.

In the troubleshooting section, I give some tips for what to do if you are stuck with low bandwidth or high latency. But if none of these work very well for you, you may need to put a high degree of effort into getting the appropriate compilers and related software onto your local PC, doing as much work as possible offline, then uploading your nearly finished work to remote Unix machines only for the final checks.

The first thing you need to do is to run an X server on the machine where you are actually seated. How you do this depends on what X server has been installed on that machine., but it's usually as simple as finding the X server in the Start button's "All Programs" menu and launching it. I'll assume for the purposes of this dicussion that you are working from a Windows PC.

Once you have an X server running, you can begin running the actual client applications. If you want to run a program that is installed on your local PC, you can launch it in the normal way via the Start menu or via a command line.

But, most likely, you are doing this because you want to run an X application on some other machine, displaying its output on your local machine. It's probably easiest if you start by running an xterm on the remote machine. xterm is simply a command window that lets you type commands to the operating system of a machine. From there, you can easily launch any other X applications you might want to run. We'll look at X applications other than xterm a little later26

It's possible that, wehen you started your X server, you may have already opened an xterm - this is particularly likely if you are using CygWin/X. If so, it's a pretty good bet that this xterm is running on, and therefore issuing commands to, your local machine. You will still need to follow the steps given below to run clients on a remote machine.

It's worth pointing out that, because it's easy to get xterm windows open to many different machines at once, it can be a bit confusing remembering which is which. Many people therefore customize their command prompt to display the name of the machine to which those commands are being sent.

This message is the most common problem that arises when trying to run X applications. Possible causes:

One serious barrier to using X on some machines is the action of other programs that deliberately block signals from the X client from reachng the local server software.

Firewalls are software security programs that many people use to protect their networks from outside hacking. One of the features of most firewalls is to block incoming communications to sockets other than the reserved socket numbers for email, http, or other services the corporation wants to support.

Similar problems arise with Network Address Translation (NAT), a scheme for allowing multiple computers on a local network to share a single internet connection. Microsoft Windows 98 and later offers a form of NAT they call “Internet Connection Sharing” . Under this arrangement, for example, I have three computers in my home that can all access the internet through a single cable modem connection. To the outside world, I appear to have only a single computer there, because all three are sharing the same IP address.

If you are connected to cable modem service via a router, you are probably using NAT, a firewall, or both.

Why is this a problem? To answer that, we need to talk a little bit about how machines provide different services to one another over the internet. Machine-to-machine communication over the internet is generally carried out by sending signals to one of several sockets, a software analogue of the hardware device that allows you to “plug in” other devices.

Sockets are identified by numbers. Some numbers are reserved for common internet services (telnet, ftp, email, and http all have their own specific socket number).

Figure 4: Making a telnet connection

For example, to make a telnet connection, your local PC sends a signal to a remote server asking for a connection on socket 23 (the socket number reserved for normal telnet connections). The server sends a signal back that acknowledges the request, and the resulting two-way communications channel is then used for your telnet session.

Figure 5: Telnet Connections Through a Firewall

If you are behind a firewall, telnet probably still works. That's because most firewalls are designed to block connections initiated from outside, but will allow requests initiated by local machines to "tunnel through".30

An exception: companies who want to prevent their employees from web surfing, using chat, etc., during work hours may set their firewalls to block even outgoing requests on the socket numbers associated with those services.

X also communicates via sockets, using socket number 6000 + display-value. For example, if your DISPLAY is set this way:

setenv DISPLAY localMachineAddress:0

then X uses socket 6000, but if your display is set this way:

setenv DISPLAY localMachineAddress:2

then X uses socket 6002.

Figure 6: Making an X Connection via telnet

An X connection begins with an ordinary telnet session. Eventually, you issue a command to run some X program such as xterm. That proram, running on the telnet server, then tries to open a connection via socket 600031

I'll assume you are using display number 0, as is usually the case.

to your local PC. If you are running X server software on your local PC, it accepts the socket 6000 connection, and a new communications path is thereby established for X windowing information.

Figure 7: X Connection Blocked by a Firewall

Now, throw in a firewall, and things get messy. From the viewpoint of the firewall, the socket 6000 connection is being initiated by an outside machine. Most firewalls will block any such attempt. The connection attempt fails, and you see the dreaded “could not open connection…” message.

If you are trying to use X from behind a firewall, your best bet is to connect via a Secure Shell (ssh), as described in Section 4.1.5.3: Running X via ssh. Alternatively, you might ask the system's administrator to permit external connections to socket 6000. If you are running a Linux system, consult your documentation on “ipchain” and/or your firewall package to see how to do this.

A similar problem arises with Network Address Translation (NAT). NAT can confound X because when an X client tries to send information to your X server software on socket 600x, the NAT software has no clue as to which of its local machines it should route that information to. Luckily, some NAT packages allow you to configure the software to route specific socket requests to specific machines. Using these instructions, for example, I set up Windows Internet Connection Sharing to route socket 6000 to one machine and 6001 to another. Then I can run X server software on either machine and, by setting my DISPLAY appropriately, have the X windows appear on the machine I'm seated at.32

And I know I've gotten it wrong when someone screams from the other room, “Dad! What's this emacs thing popping up on my screen?”

But the simplest way around this problem is to launch your remote programs via ssh, as described in Section 4.1.2.2.1: Launching via an ssh command and Section 4.1.2.2.2: Launching via PuTTY.

30. An exception: companies who want to prevent their employees from web surfing, using chat, etc., during work hours may set their firewalls to block even outgoing requests on the socket numbers associated with those services. (back)

31. I'll assume you are using display number 0, as is usually the case. (back)

32. And I know I've gotten it wrong when someone screams from the other room, “Dad! What's this emacs thing popping up on my screen?” (back)

4.1.5.3. Running X via ssh

When you use ordinary telnet, ftp, or X over the internet, information to and from your PC are being sent as clear text. In theory, anyone else connected to the same local network as you (or as the machine with which you are communicating) could be reading the packets of information flowing by, writing down your passwords, etc.

Secure Shell (ssh) is an alternative set of internet tools that provide telnet-like and ftp-like capabilities but transmit all information in encrypted form, thus foiling potential eavesdroppers.

I mention this here because ssh has another benefit -- it can be used to “tunnel” the X protocol through many firewalls and NAT systems.

Figure 8: making an X Connection via ssh

ssh conections start off much like telnet connections, though the socket number is 22 instead of 23. But if X tunnelling has been specified, and we send a command to the ssh server to start running an X program, things get very different.

Our ssh connection on the server will run with a $DISPLAY value that maps right back to the ssh server, though usually on an unusually large display number. Therefore when the X program tries to open a connection to the X server that will display its windows, it connects to itself, on a socket number that is watched by the ssh server software. That ssh server software then sends a signal along the already-established ssh communications path indicating that an X connection was attempted. Back at your local PC, your ssh client software then opens a connection to socket 6000 on your local PC, where it gets picked up by your X server software.

All of this is invisible to the firewall, because the "new" X connections don't cross the firewall, and the actual X information is channelled along an already existing ssh communications path.

To do this, you need two things:

1. The machine that will be running the X applications (the X client) must also be running an ssh server. Our lab.cs.odu.edu and fast.cs.oddu.edu machines all run ssh servers.
2. The machine where the X windows graphics are to be displayed (the X server) must have an ssh client program available.

Where do you get an ssh client?

Newer versions of X-Win32 and Exceed already include ssh support. Beware, however, of the X-Win32 distribution provided by ODU to all ODU students under its contract with StarNet. Once you enter the registration code for that distribution, it is limited to connections made with machines at ODU's IP addresses (128.82.??.???). But, as the diagram above shows, when we tunnel X through an ssh connection, the connection to our local PC's server comes from that same PC itself (using a special IP addresss 127.0.0.1, which is reserved to mean “local machine” - not via the network). Since that address doesn't begin with 128.82, the ODU distribution of X-Win32 refuses those connections.

• You can use X-Win32 from ODU's web site if you don't give it the ODU registration code.
• You can use X-Win32 downloaded from StarNet's own web site.

Either way, without a registration code, it runs in “demo” mode where it must be shut down and restarted every two hours.

ssh is also available as part of the CygWin package. And the PuTTY program, recommended earlier for use as a Windows telnet client, also makes a good ssh client. Finally, check out this list from the OpenSSH project at http://www.openssh.org.

4.1.5.4. X Applications Seem to be Unreasonably Slow

Contents:

4.1.5.4.1 Low Bandwidth Connections

4.1.5.4.2 Low Bandwidth Connections

The first thing to consider is whether your problem is likely a matter of low bandwidth or high latency, as explained in Section 4.1.1.1: X Performance and Your Internet Connection.

Low Bandwidth Connections

If your connection is slow at doing all manner of things that require tranferring large amounts of data (e.g., downloads, viewing web pages with large images or videos), your problem is likely to be a low bandwidth internet connection. This is particularly likely to be a problem if you are connecting over a conventional dial-up modem, though it can be an issue for some supposedly high-bandwidth ISPs as well. Bandwidth problems can also arise if you have a good internet connection coming into a wireless router, but then connect to that router via a slow wireless connetion.

Some things to try:

1. On dial-up modems, watch your connection speed. Even if you are using a 56k modem, you might wind up with a much slower connection. Furthermore, your connection speed may actually go down as time passes if your phone connection encounters a lot of line noise.

   Sometimes you can do better just by hanging up and reconnecting.

2. Choose your applications carefully. Even at modem speeds, xterm and emacs are generally going to run at perfectly usable speeds. Applications with fancy toolbars and graphics may run slowly, or may take a long time to appear on your screen but then run at acceptable speeds. For example, over a 53.3k connection, I find that emacs is ready to run in under 20 seconds, but ddd takes almost 4 minutes to appear (though its speed is OK once it finally appears). So, if I need to run a debugger, I am more likely to run gdb-mode within emacs than to use ddd.

3. You can reduce the amount of network traffic required by X by telling your X server sofware to always use a “backing store” . In X-Win32, this option is found by right-clicking on the small blue “X” , selecting X-config, and going to the “Display” tab. A backing store is simply a copy of the window's grpahics kept in your local memory. This can be used to refresh the screen when part of your X application gets momentarily covered up by some other window, or if you iconify the X applicaiton and then restore it from the task bar. Without a backing store, all the graphics may need to be retrieved from the remote client over your modem connection.

   This won't speed up all applications (the default setting of many X servers is to use a backing store only if the application program requests one, so some X applications may already be getting a backing store). But, for some, this might make a big difference.

4. There is a very good chance that your X server software supports a special extension to X that compresses packets before sending them over the network. This is called LBX (Low Bandwidth X).

   To use LBX, make your connection to the Unix machine on which you want to run your X client applications. Make sure your X server is running on your local machine. Set the DISPLAY on the remote machine and test it by running something simple (e.g., “xterm &” ). If all seems well, shut down that that simple program and then do the following on the remote Unix machine:

   lbxproxy -display $DISPLAY -terminate :1 & setenv DISPLAY unix:1 xterm &
   You should get a new xterm window. Now any X clients that you run from that new xterm are actually being routed through the lbxproxy program, which compresses the X packets before sending them on to your local server. When you exit from all the compressed X client applications, including that new xterm window, the lbxproxy will shut down.

5. Instead of using lbxproxy, you can achieve a lesser degree of compression by using ssh (see Section 4.1.5.3: Running X via ssh). Adding a -C option to your ssh commands will request additional compression.

Low Bandwidth Connections

If your connection is fast at doing all manner of things that require tranferring large amounts of data (e.g., downloads, viewing web pages with large images or videos) once the data starts flowing, but you have to wait a long time for things to start, or if, when you work in telnet, you seem to get long pauses after issuing each command , your problem is likely to be a high latency internet connection. This is particularly likely to be a problem with broadband services that route you through satellites.

You can certainly try the fixes listed above for low bandwidth connections. If your problem is really latency, they are unlikely to help. But they probably won't hurt either, and if your problem is really a combination of low bandwidth and high latency, you ay see some improvement. Otherwise, try these:

1. Get out the old modem and find a cheap dial-up ISP. I have had students in remote, mountainous regions report that, although they would continue to use their satellite broadband (their ownly available broadband option) for web browsing, they got better responses by using dial-up for their programming work.

2. Try connecting to an X session via VNC. VNC will likely require higher bandwidth than X, but some students have reported that it works better in high latency situations.

4.1.5.5. “xterm: unable to locate a suitable font”

This message is usually caused by a font configuration problem on the Unix side. There is a simple workaround, however.

Log into your Unix account. Using emacs or some other editor, create a file named ~/.Xdefaults In that file, place the following lines:

xterm*Font:-*-lucidatypewriter-bold-r-*-*-12-*-*-*-*-*-*-* xterm*Geometry:80x36 xterm*foreground:midnight blue xterm*background:white

(Actually the first line is the critical one for this error - but you might find the effects of the other lines interesting. You may also wnat to paly around with other combinations.)

4.1.5.6. “connect localhost port 6000: Connection refused”

The important thing about this message is that it indicates that the problem was with “localhost” (or “127.0.0.1” ), which is the local machine that you are sitting at. The problem is not that some remote machine out on the internet has refused you access, but that the machine you are sitting at has in fact refused to allow a connection from itself to itself.

This is pretty much an obvious sign of a firewall or other security program getting in the way. You might have gotten a pop-up window warning that a program (either XWin.exe or ssh.exe) was trying to make or accept a connection on port 6000. If you told the firewall to block it, that's the problem. If your firewall or security program is set to block unexpected connections without even asking you, that could be the problem.

The easiest way to check this would be to teporarily turn off your firewall and security software, then try launching an X client again. Unfortunately, I've seen some cases where even a switched-off firewall stays partly active and continues blocking things that it believes it has been previously told to block.

The exact fix for this depends a great deal on what firewall/security software you are running, but somehow you need to convince them to trust XWin.exe and ssh.exe. Here are instructions for telling the Windows firewall to allow exceptions. Try adding XWin.exe and ssh.exe as exceptions (browsing to the directory where they are installed, probably c:\cygwin\cygwin\usr\X11R6\bin\XWin.exe and c:\cygwin\cygwin\bin\ssh.exe. You might also want to try opeing port 6000.

4.1.5.7. “connection refused by server” or “Client is not authorized to connect to Server”

The "not authorized" and "refused by server" messages means that you got at least part way through the process of forming an X connection. The X client (xterm) running on the remote machine was able to actually talk to your X server software (running on the PC you are seated at) but your X server software's security settings shut it down.

This message generally comes from StartNet's XWin32. I've never seen it reported from users of Cygwin/X.

Things to check:

• If you are using ssh to connect to X-win32, and if you downloaded it from the ODU site, then it is important that you followed these instructions for installing it, rather than the instructions included in the downloaded package.

  In particular, did you enter the OCCS registration key during installation instead of just "demo"? (XWin32 should warn you that you are in demo mode every time it starts up.) If you entered that code, you cannot use ssh to launch a session and therefore cannot use X-Win32 from behind a firewall/NAT server. You will need to uninstall X-Win32 and then reinstall using my directions.

• Run the X-Win32 X-config program and check the "Security" tab. Make sure that "Access Control" and "Use XAuth" are both clear. Click OK in X-config and shut down XWin32 if you have it running. Restart XWin32 and try to connect again.
• If you still get the "not authorized" message, then go back to that security tab again. This time, click "Access Control" and use the "Add..." button to add to the X-host list:
  localhost 127.0.0.1
  Again, click OK in X-config and shut down XWin32 if you have it running. Restart XWin32 and try to connect again via ssh.

4.1.6. Alternative & Related Technologies

Contents:

4.1.6.1 Remote Desktop Protocol (RDP)

4.1.6.2 Virtual Network Computing (VNC)

X is one of the earliest protocols to support a GUI connection to remote machines, dating back to 1984. Not surprisingly, alternatives have arisen, though sometimes for slightly different purposes. In particular, conferencing systems allowing various degrees of application sharing or desktop sharing are a hot topic. In addition to those, a couple of desktop sharing systems worth mentioning:

4.1.6.1. Remote Desktop Protocol (RDP)

Most Windows systems feature a remote desktop capability. You have to activate it to show anyone your desktop. Viewers (called RDP - Remote Desktop Protocol - viewers) are common even for Linux and other non-Windows systems. Some Linux distributions now offer RDP servers as well, allowing you to access their desktops from remote locations.

4.1.6.2. Virtual Network Computing (VNC)

VNC is a popular solution for small groups who want to view and/or manipulate a shared desktop. Windows, Linux, & Mac machines can all participate equally. You need someone to "host" the group by running a VNC server. The host machine's screen will be visible to everyone who joins the session. Optionally, these remote participants may be able to supply mouse and keyboard input as well.

I recommend TightVNC, a free VNC package with a lot of nice features. One convenient one is that only the host absolutely needs to install the software. The server can generate a web page that runs the viewer as an applet. All the non-host participants simply direct their browsers to a special URL and the viewer software will be loaded and run automatically. (Of course, there is also a non-applet viewer that is a bit faster and offers more options/features.

The trickiest part of hosting a VNC session is that everyone else must be able to conenct to a specific port (or pair of ports) on the host machine. This may require opening a special hole in your firewall. It's a reasonably safe thing to do, but the procedure varies according to the firewall/router you are using, and some people may stumble over this.

Another option would be to run a VNC server on one of the CS Dept Unix machines, then connect to it to view the "desktop" on that Unix machine. Since this "desktop" is actually an X session, VNC can actually be used as an indirect way of running X-based applications. Some people have reported that this approach works better than a direct connection if their internet conenction has high latency.

To do this, ssh or telnet in to one of the CS Unix machines. For the sake of this example, let's say you chose tango.cs.odu.edu. On that machine, give the command

vncserver :NN -once

where NN is a two-digit number. I'd suggest starting around 20. If you get a message saying that there is already a vncserver on that port, try a different number. Eventually you should be asked to pick a password. Choose one. If you are using VNC just as an X alternative, this password prevents others from hijacking your X session. If you were using VNC as a way of collaboriating with other people on a team project, you would let them know the NN you chose and the password via email, telephone, IM, etc. (This same password will be used for any future VNC sessions you create unless you delete the file ~/.vnc/passwd).

Now that a VNC server is running on your chosen machine, you need to run a VNC viewer (e.g., vncviewer.exe from the TightVNC package) on your local PC. When asked what machine you want to connect to, respond with tango.cs.odu.edu::59NN, replacing the NN by the two-digit number selected earlier. Of course, if you chose a different machine other than tango, change that name too. Also note that those are two colons between the machine and number, not just one.

Figure 9: An X Session via VNC

You should then see a large rectangular window open up with a smaller window inside it (Figure 9: An X Session via VNC). The outer rectangle is a "virtual desktop". The inner window is an xterm running on the Unix machine. Try issuing a few commands in that xterm. Try moving it (click on the title bar and drag). Click on the open area of the desktop to open up a menu of basic desktop options.

When you done, shut down the server by giving the command

vncserver -kill :NN