PCs and Serial X
Brad Weinert Support for mobile computing, telecomputing, and remote access to UNIX and PC-based LANs has been problematic in the UNIX/X Window environment. Until recently, the only way to connect to a UNIX LAN and access X Window applications was to use the standard SLIP/PPP IP protocol. While this solution works, it is inherently slow and cumbersome, as well as unusable for many users due to the extreme network bandwidth required by the X protocol. Compared to character-based applications, for which standard serial lines were sufficient to send and receive data, the graphics-based X Window environment is much more complex -- it is not unusual for several megabytes of data to be transferred between the X client and the X server during a session. Transferring such large amounts of data over a standard serial connection is impractical at the very least. One solution is to provide dedicated telephone lines that support much higher transmission speeds, such as T1 leased lines. The obvious disadvantage is that dedicated lines are expensive and require hardware on both ends. In a setup of this kind, providing remote login capabilities would entail establishing a dedicated phone line for each user who needed to connect to the system. X Window vendors such as Tektronix and NCD have recently developed proprietary protocols that allow users of standard serial and phone lines to greatly increase the throughput over these lines and provide their users with acceptable performance even at transmission speeds as low as 9600 bps. Combine these proprietary protocols with a pair of high-speed modems and you begin to see a solution for remote X Window connections. Protocols To increase performance, the proprietary protocols typically include compression algorithms, proxy servers, and caching. For example, Tektronix' Serial Xpress uses data compression techniques along with host- and server-based applications to provide throughput acceptable to most users. Serial Xpress starts with a host-based proxy server. This proxy server interprets the X protocol intended for transmission over the serial line, compresses the data, eliminates redundant requests, and responds to requests locally whenever possible. The proxy server also combines requests when it can and uses intelligent data caching, eliminating the need to continuously reread protocol requests coming in or going out over the serial line. On the other side of the serial connection, the X server is optimized to provide similar capabilities. You end up with two servers, processing as much data as possible locally, then compressing remaining data before sending it over the serial connection. Other vendors, going one step further, have adopted the proprietary protocols and added enhancements and additional software for UNIX hosts and X servers. As a result, these protocols not only run over standard serial lines without TCP/IP, but also in conjunction with SLIP and PPP. The advantage is that you regain the functionality that you otherwise lose by going with proprietary protocols, while maintaining the performance enhancements that you get by using the proprietary protocols. For example, you could use the Serial Xpress software and a local X server or X terminal to run X Windows applications from home. You would have access to the complete functionality of your X clients, just as you would if you were sitting in your office, although slower. What if you need to ftp some files, Telnet to another host, or NFS-mount a printer? Since these relatively standard tasks require the TCP/IP protocol, there are two solutions: you could maintain two separate configurations -- one for standard SLIP/PPP connections, and one for proprietary X connections such as serial Xpress; or you could use software that supports both proprietary serial X protocol and SLIP or PPP protocols simultaneously with little performance degradation. Setting It Up Because I'm most familiar with the Serial Xpress technology from Tektronix, the examples that follow are based on that model. Please note that the functionality, configuration, and performance of the NCD Xremote product is very similar. The X Window system is a client/server-based technology, so there are always two parts to the equation, the client application program or task, and the server software that fulfills the request of the client, in this case, drawing and input-output requests. In this model the client resides on the UNIX host and the server resides on the PC. There are several things you must do in order to display an X client on the remote PC. First, you must dial up the remote UNIX host. Any standard modem configuration will do -- the only requirement is that the connection must be eight data bits for both Serial Xpress and Xremote software. Larger or more complex, security-conscience sites will probably have an external dial-in annex or gateway where authentication takes place. The serial technology discussed here works well in either environment, but for the sake of brevity, consider the modem as connected directly to the UNIX host. The following sections show two examples of setting up a modem directly connected to a UNIX host. Other UNIX hosts will have similar configurations. IBM Configuration To configure an IBM RS6000 series host for use with Serial Xpress, you must configure the host serial ports. The host's serial port settings must match those for the modem or PC. If the serial ports have not been added and configured, use the System Management Interface Tool (SMIT), following the steps below, to add and configure a port: 1. Choose Devices->TTY->Add a TTY->. 2. In the Single Select List window, select the type of port to add (for example, tty RS232 Asynchronous terminal). 3. In the next Single Select List window, choose the port on the parent adapter (for example, tty0). 4. Configure the port as follows: Baud rate: 9600 (9600+ recommended, but lower rates will work) Parity: None Stop bits: 1 Bits per character: 8 5. Exit SMIT. If a port has already been added and configured, you can view the configuration settings and make any necessary changes as follows: 1. Using SMIT, choose Devices->TTY->Change/Show Characteristics of a TTY->. 2. In the Single Select List window, select the port whose settings you want to view (for example, tty0). 3. If necessary, edit the settings to conform to the specifications below: Baud rate: 9600 (9600+ recommended, but lower rates will work) Parity: None Stop bits: 1 Bits per character: 8 4. Exit SMIT. SUN Configuration for SunOS To configure a SunOS host for Serial Xpress, you must set the ports for RS-232 mode, then configure the ports. If your host is set for RS-423 mode (the factory default), power down the host and change the serial port jumpers on the main logic board to RS-232 mode. Refer to the Sun Installation Guide for details. To configure the ports, you'll need to edit the /etc/ttytab and /etc/gettytab files. The ttytab file, read by the init process, specifies which serial ports will have a login process created for them. The gettytab file displays the values that the host recognizes for different bps rates, performing such tasks as setting the bps rate and reading the login name. Superuser privileges are required to edit the ttytab and gettytab files. The following steps are required for the SunOS configuration: 1. Edit the /etc/ttytab file to configure the port you are using (ttya or ttyb). The fields in this file are: name -- specifies the device name. getty -- specifies the program that the init process should run. Replace std. with sxp. to specify Serial Xpress. type -- specifies the termcap entry designed for the terminal attached to the port. For use with Serial Xpress, enter vt220 as the type. To see a list of available terminal types for your system, open the /usr/share/lib/termcap file. status -- specifies On or Off. If On, init creates a login process. If Off, init ignores the line and a login is not allowed. comments -- specifies comments. If the comment is "secure," users will be able to log on as root. 2. Edit the /etc/gettytab file to add a new entry for the bps rate you are using. For example, if you are using a bps rate of 19200, this entry would read:
sxp.19200:\ :p8:sp#19200:
The :p8: specifies eight-bit operation, required for Serial Xpress. 3. Set the flow control to CTS/RTS by adding :ms=3Dcrtscts: to the line edited in the previous step, as in the following example:
sxp.19200:\ :p8:sp#19200: :ms=3Dcrtscts:
Although Serial Xpress will function without flow control, you should use the CTS/RTS setting for maximum performance. Avoid using XON/XOFF flow control, because in a noisy environment a bit pattern might be mistaken for XOFF and the terminal might stop sending data. CTS/RTS flow control can also be set by entering stty crtscts in a Serial Xpress window before launching XoftWare/32 for Windows. 4. After editing the ttytab and gettytab files, restart the init process by entering kill -HUP 1. The init process rereads the ttytab and gettytab files and restarts the program specified in the ttytab file for each line whose status is On. Completing the Setup The PC on the other end of the phone line needs a modem compatible with the modem installed on the UNIX host. Remember that in this case faster is better, so get the fastest modem that your budget will allow. I recommend that you not attempt this at speeds lower than 9600. You will also need an X server and serial connection software that will allow you to dial your UNIX host, establish a connection, start the X server, and display the client on the remote PC. Again for the sake of this discussion, I will use Serial Xpress software as the example. NCD's Xremote product is very similar in configuration and requirements. All of the PC X Server packages that can do this work are based on Microsoft Windows. Some offer more complete feature sets and capabilities than others. Some are more expensive than others. Some use the Tektronix technology, some NCD. Pick the one that suits your needs best. Installation of the PC-based software should be straightforward. Follow the software manufacturer's recommendations on system hardware and software requirements. The serial connection software will come with the UNIX host-based proxy server software. This is the software that controls the connection to the X server from the UNIX side and does the data compression before transmitting to the remote PC. This software must reside on the UNIX host where the initial connection is to be made. If you're using an external login device such as an annex or other modem pooling device, the host software still must reside on the UNIX host. So, for example, a user logs in to a modem pool, he/she must then rlogin or telnet to a UNIX host and start the proxy server before the session can begin. You must copy the appropriate host software to your UNIX host in a directory where users can reach it, as they must start this software every time they log in to the host to begin a serial X connection. Getting a Connection Once you have attached a modem to your UNIX system, configured your ports, installed software on the remote PC, and installed the UNIX host proxy server software, you are ready to attempt your first session. The sessions are always initiated on the remote PC side, and there is typically a user interface in which the user specifies the phone number and other parameters needed to make the connection. An example is shown in Figure 1. Starting X Once you have made the initial connection, it is time to start the proxy server that allows this entire process to function. This is usually done by starting a process on the UNIX host. In the case of Serial Xpress, this process is called sxprocess. This program is host-specific and it is critically important that you use the correct one for your host and operating system. In most of the PC implementations, once the initial login is achieved, an interactive window similar to a telnet window is opened so the user can start the desired process. The process, in this case sxprocess, then begins talking to the PC and an X server is started on the PC. Once the X server is initialized, clients can be displayed on the remote PC's screen just as they would if the user were connected over a TCP/IP network. Both Serial Xpress and Xremote offer session scripts that allow users to specify a set of clients to be launched every time they log in. Performance So now you're logged in. You've started some X clients. What kind of performance should you expect? This depends on many factors, not the least of which is the speed of your modem. The processor speeds of the PC and the UNIX host also help to determine the ultimate throughput, since the X server and proxy server play a major role in the transmission and display of X clients on the remote PC's screen. I performed several simple benchmarks to show the relative performance of X Windows over a proprietary protocol, a standard serial IP protocol, and a TCP/IP protocol. The tests were simple and not meant to thoroughly test the performance of each of these platforms. As with any piece of hardware or software, you should test in your environment with your applications to determine if the solution meets your needs. I selected three standard procedures to test the relative performance of each of these operating environments. 1. Start X server and display an xterm. 2. cat /etc/termcap (69Kb file) 3. Run xengine The software I used for this test was AGE Logic's XoftWare/32 for Windows Serial Edition. Xoftware/32 for Windows uses the Tektronix Serial Xpress technology. For the TCP/IP test, in both PPP mode and connected to an Ethernet network, I used Novell Lan Workplace for DOS version 4.12 as my TCP/IP network stack. My PC was a Gateway 2000 4DX2-66V (66Mhz 486) with 16Mb RAM and a Practical Peripherals PM14400FXMT modem. The modem was set to run at 14.4K bps with no data compression. I connected to a Sun Sparc 5 running Solaris 2.3. An identical modem to the one on the PC was connected to the Sun host. Table 1 shows the results of this test. As you can see, even in this simple test there are noticeable differences in performance between a standard PPP connection and the Serial Xpress connection. On the other hand, there is still a substantial difference between TCP/IP over Ethernet and either of the other protocols (modems just aren't as fast as Ethernet yet). Still, given the growing demand for remote access among X Window users, you may expect continued improvement in performance and functionality in the area of serial X.
About the Author
Brad Weinert is Manager of Technical Services at AGE Logic, Inc., of San Diego, California. Brad has been active in the software development and information systems support market for over 15 years, and has a strong background in UNIX, Novell, X Window, MS Windows, PCs, and telecommunications, and has consulted for a number of Fortune 500 companies.
|