Netcom II allows your programs to interface to X.25 virtual circuits established by X.3/X.29 PADs as UNIX serial ports (tty devices). The tty interface is defined by SVID (the System V Interface Definition) and serial ports follow this same standard. So if you understand serial ports, you are a long way towards understanding using X.25 virtual circuits with the tty interface.
When a terminal interface is used with X.25, generally the X.29 protocol is used along with X.25. The X.29 protocol provides a mechanism for the application at one end of the virtual circuit to control the actions of the terminal application at the other end. The control commands may change throughout the conversation depending on what the application is doing.
For example, if you are remotely logged into your UNIX machine and entering commands at the prompt, the shell cannot do anything until you press the enter key or some special character like the interrupt key. In this case, the terminal would be set up to handle data entry locally with echoing to the screen, only forwarding the data to the remote system when the enter key is pressed. This allows the data to be sent in a single packet, which is much more efficient than sending each character as it is typed.
Alternatively, suppose you were logging into the remote UNIX machine and entering your password. It is still desirable for the terminal to gather the characters as you type them (until you press enter), but now the terminal has to be told not to echo the characters to the local screen. Finally, suppose you start using vi. Now, the terminal must forward each character as it is typed (such as the letter i to enter insert mode). It cannot wait for you to press the enter key.
This change to the terminal's characteristics is done by using the X.29 protocol. If you look at the trace, X.29 packets are distinguished by having the Q (Qualifier) bit set in the packet level header. This bit tells the host application and the terminal that the data in the packet needs to be interpreted as a command/control information rather than user or application data.
While the X.29 protocol details how to communicate terminal control information, the X.3 recommendation details the actual items that can be controlled. From the above examples, there are parameters that control the local echoing of data at the terminal (X.3 parameter 2) and when the characters will be forwarded from the terminal to the host application (X.3 parameters 3 and 4).
So how does the X.25 driver know what kind of application is running on the host in order to set the X.3 parameters correctly? In UNIX, applications control tty interfaces using ioctl() commands. Running stty -a on your UNIX terminal, even if it is the console, will show your current terminal modes. The X.25 driver maps these terminal modes into X.3 parameter settings and, when one changes, this change is communicated to the remote terminal using an X.29 packet. The X.3 Parameters topic provides a complete mapping between terminal modes and X.3 parameter settings.
In the above description, terminal was used to describe the user input side of the virtual circuit. In reality, it would be a PAD (packet assembler/disassembler) which converts the keystrokes from the user into X.25 packets and displays the X.25 packets it receives on the screen. This PAD may be a box with asynchronous terminals plugged into it or it may be an application like xpad which does the same thing in software for UNIX users (xpad is included with the software). Also, the data input need not be coming from a user sitting in front of a screen. The tty interface, when used to make outgoing calls, allows a program to automate the input functions and connect to any application on the host side, either for entering data as a user or passing generic information between programs. The tty interface is used for incoming calls, it is now the host application in the above description, and the mode changes made by the application to the tty device control the remote terminal.
Extensive X.29 support is in the "tty" driver. When applications use the X.25 devices in tty mode (such as getty and login), the driver translates the termio modes into X.29 commands to change the remote PAD parameters. This off loads the host from processing such as echo and line editing. More importantly, echo is done by the remote device where it will be much faster.
Immediately after the driver accepts a call from a remote PAD on a tty device, it sends the PAD a non-specific Qualified "Read Parameters" packet to determine its current parameter settings. It alters the PAD parameters according to tty ioctl() commands from the UNIX application.
The driver only uses the parameters for which the PAD indicates support by providing values for them in its current parameter settings response to the initial "Read Parameters" packet.
The padd override parameters may be used to unconditionally override any of this automatic X.3 parameter manipulation by the driver, even when the remote PAD indicates that it has support for the parameter.
See Overview of X.29 and X.3 for an overview of X.29 and X.3 or X.3 Parameters for a table mapping tty settings to X.3 parameter settings.
Copyright © 1997-2002 The Software Group
Limited. All Rights Reserved.
® Netcom is a registered trademark of The Software
Group Limited.