What are Network Redirectors?
by Stuart Baker
Having recovered from the long interesting days at Interchange 91 and COMDEX, I am looking forward to Interchange 92! Somehow, my sensitive palate will once again survive New Orleans (Who Dat, Who Dat, Who Dat).
Every time I attend the annual Interchange conference, I am reminded that many things I assume are common knowledge, are not. This year, network redirectors were among the least understood topics. This article fills the knowledge void and brings everyone up to speed on this important topic.
First, a little background on PC communications. Since the introduction of the original IBM PC, it's BIOS (Basic Input Output System -- in ROM) supported communications over serial ports through the use of INT 14. This basic support exists virtually unchanged in today's 486 machines (shall we call that a standard?). Was the original design all encompassing? No, not even close! As software developers soon discovered, the BIOS support is virtually unusable. The most severe limitation of the basic INT 14 support is its propensity for loosing data. For example, if a program uses INT 14, chances are that it will not be able to support speeds greater than 1200 bps on 386 class machines without the potential for loosing data. The BIOS performance is poor because it does not perform data buffering or use the serial port interrupts. Because of its poor performance, INT 14 went virtually unused for many years. Today every quality communications program has to take control of the hardware to get the required performance from the serial ports.
In this day of inexpensive PC networks, many machines are connected together to share expensive peripherals. In our office, our PC's are connected together with a Ethernet network. We share disks, a PostScript printer, streaming tape and serial ports to an in-house 3212 system. The access to the serial port is through the INT 14 interface I have just described, but we access the serial ports at 19,200 bps. How? Network Redirectors. But how can it support such high speeds you ask? We will address that topic shortly.
As networks became affordable (and therefore popular), it was only natural that someone would want to access a serial port over the network. Where does one start. The logical starting point is the only universal (but largely unused) method of accessing serial ports, INT 14. A network redirector is a TSR (Terminate and Stay Resident) program that intercepts the INT 14 request and performs the function for your program. The process is very similar OS/32's intercept function. This TSR effectively replaces the original ROM BIOS INT 14 support and simulates the original functions. In the case of an Ethernet network, characters that you write are placed into a packet and transmitted over the network. When a packet with data arrives, the characters are supplied to your program as if they had arrived over the serial port. In general, your program is not aware that the intercept is occurring.
What about the poor performance? Not a problem over the network, the data is buffered and error checked by the vary nature of the network.
As I mentioned earlier, the INT 14 support is virtually unchanged from the first implementation on the PC. The original INT 14 standard allows a program to send and receive data, select speed (up to 9,600 bps), set parity, stop bits and word length. You can even check the status of some of the modem lines.
The original design imposed a significant performance penalty when an application program attempts to receive data. Using the original INT 14, a program had to issue two interrupts, one to check the status and if a character was present a second INT 14 was needed to obtain the character. If a program tried to obtain a character before one was present, it was suspended until a character arrived or the watchdog timer (several seconds long) expired. The basic design needs to improve before performance can really be boosted.
When you review the above list of supported features you will see that, in addition to it's poor performance, there are several communications options that are not supported. INT 14 does not let you send a break, select speeds above 9,600 bps, control modem signals like DTR and RTS, perform no wait reads, support low level (ISR - Interrupt Service Routine) flow control or buffered reads! Since most of the functions just mentioned are critical to the functionality of a good communications program, additional support must be added before INT 14 is truly practical to use.
Along comes the IBM/Yale EBIOS extensions. These extensions to INT 14 (intended primarily for use in network redirectors, but they could be applied to programs designed to enhance the basic INT 14 support) address all of the problems mentioned above. You can now send the much needed break signal, a must for OS/32 users. You can disconnect a modem by dropping DTR. Overhead in receiving data is reduced through the no wait read request. The EBIOS extensions also allow you to establish a buffer for sending and receiving data. You can also request that the low level ISR routines honor XON/XOFF flow control.
The designers of the EBIOS implemented a method of detecting the presence of EBIOS support, so the user does not need to worry about the details. The communications program can detect the presence of EBIOS and automatically tailor itself to support the new services.
By using network redirectors, like the Novel Virtual Terminal (NVT), you can now use programs like PC-Passport to access your RTU systems directly over a network. Concurrent is working on adding this support into OS/32, but for now a user on a PC can connect to a RTU system over the Novel network and then use RTNET from that RTU system to access Reliance on a OS/32 system. All this without even one serial port in sight!
Network redirectors are your answer if you have a need to let users of PCs access your Concurrent system over a network. The server can have a pool of serial ports connected to your OS/32 system, allowing users from any PC on the network to access the OS/32 system as if they were directly connected. This eliminates the problem of running point to point serial connections from every PC, and reduces the number of serial ports required on your OS/32 system.
Well that about does it for this issue. It was nice seeing many old friends at Caesar's Palace and a real pleasure finally meeting friends that I have previously known only over the phone.
This SBSW.COM page has been optimized for printing.