We assume that anybody who stops to contemplate the different types of "time sharing lines" you can gen in with TSX might find it a little confusing. This small article was written to answer the question, "what's the difference between a TTY, a PTY, a virutal terminal, and all that jazz"?
A historical perspective which explains the motivation for these terminal types is probably a good way to gain the insight you are seeking.
In the beginning, there were only ordinary time sharing lines. In keeping with the general scheme for naming devices with a two character device type, a controller letter, and a unit number, and in keeping with the device type names from TSX-Plus and VMS, these time sharing lines were given names like TTA0:. That's device type TT (just pretend it stands for TeleType), controller A, unit number 0. We used controller A unit 0 for the console, controller B for the COM1 port, C for COM2, and D for the first serial mux, so it's nearly always (but not necessarily) the case that the console is TTA0:, COM1 is TTB0:, COM2 is TTC0:, and the 8 lines of an 8 line serial multiplexor were TTD0: through TTD7:.
By the way, we were worried about that 8 line mux, because the ports on it were numbered 1 through 8, and there TSX was calling them 0 through 7. We thought this could confuse people. So, we introduced the /BASE_UNIT qualifier so that some devices can have lines named TTD1: through TTD8: instead.
The important thing to realize about "TT" type devices is that they are physical, 3 dimensional entities in the real world.
Next came network virtual terminals. To accept an incoming Telnet or SET HOST connection, TSX creates a temporary (non-physical, entirely "in memory") terminal for the job. We called these devices "TT" also, but used the controller designation 'N' for them for "Network". Hence you notice that your telnet users are all given terminal names like TTN1:, TTN2:, and so on. These terminal lines are created when a network connection starts and are destroyed (deallocated) when that job logs off.
The motivation for virtual terminals may have been for testing purposes. As you might expect, during the growing years of TSX, we had to test various things like logging on and off, running programs, printing to serial terminals, and so forth. However, we only had so many physical terminals, and we only had so many physical serial lines.
Having written drivers for various brands of serial multiplexors, it struck Dan that it would be a trivial project to write a driver that did not have to communicate with any physical device at all. This "virtual terminal" driver would just take any characters that it was supposed to send out to its device and discard them. Incoming characters could be emulated by the TUTOR program. Hence the virtual terminal was born. We decide to use the two character device name "VT" for virtual terminals.
To TSX, a virtual terminal is just like a time sharing line on a Maxpeed or Digiboard multiplexor, except that it never conflicts with other cards in the system! Virtual terminals can have start-up command files associated with them, you can tutor them and spy on them, the spooler can print files to them, and so on. This mechanism allowed us to do the testing we needed to do without tying up physical resources, and it turns out to be handy to users as well. Suppose, for example, you have some program that needs to run continuously, that displays a screen showing what it's doing, and can be controlled from the keyboard. If you run the thing on a virtual terminal, it's out there running in virtual reality without interfering with any real line. Furthermore, you can tutor the virtual terminal whenever you want, to see what it's doing or control its behavior.
Since virtual terminals are granted all the rights and privileges of real terminals, they can be set /NETWORK and become TCP/IP interfaces. This is used when hosting multiple domains on a single TSX system. These interfaces created by the virtual terminals have different IP addresses and are then available for programs like the web server and the SMTP server to accept incoming connections.
Before we move on, let's review the difference between physical TT terminals and virtual VT terminals. Virtual terminals are just like physical terminals except that the driver for them does not have to communicate with a physical serial device. It discards all outgoing characters and there is no way for incoming characters to come in except via TUTOR.
There is a loadable driver for virtual terminal lines just as there is a loadable driver for Maxpeed serial cards and digiboards. The handler for Maxpeed is LHMXSS8.REX, and the handler for virtual terminals is LHSHTTV.REX.
When a virtual terminal is set /NETWORK, the TCP/IP code places itself in front of the virtual terminal driver, just as it does with physical terminals. In this case socket connections from remote network clients are created, and characters do flow from these remote clients into the network code on the TSX system, and programs running on the TSX system send data out the virtual interface to the clients as well. Don't worry, it boggles our minds too.
As history progressed, customers often griped that the networking code could not be made to automatically work through modems. It CAN work through serial connections -- the SLIP code was always part of our networking, and PPP came later -- but there is no logic in TCP/IP to realize that there is a modem between two computers, stop and dial a phone number, and go through some logon script before sending an IP packet.
It then occurred to us that we could write a driver that was sort of like the virtual terminal driver, except that it would worry more about the data flowing through its device. This is the Pseudo-Terminal ("PT") driver. It exists soley for the purpose of making the networking code work through modems, and here's how it works:
Just as you can set a physical line or a virtual terminal /NETWORK, pseudo terminals are always set /NETWORK, so that they become TCP/IP interfaces. What we are doing here is faking out the TCP/IP code into believing that they are physical serial lines with cables connected to other computers.
When the system first boots, these PTY lines are not connected to anything so there is little chance that IP packets are going to flow into them. But suppose that you tell TCP/IP that it's a physical line connected to another computer using SLIP, and you ask it to transmit a packet out the line. Maybe you try to telnet to the computer you've claimed is on the other end of the connection, or maybe you try to send it some email. TCP/IP will do its thing, make a packet, and call upon the interface to transmit the data. That's the point at which the first character of the first packet would be presented to the driver for a physical serial card for transmission.
The PTY driver, which is linked into the operating system (not a loadable .REX file), receives the request to transmit this character and becomes deeply concerned, because it can't transmit a character out a virtual device! So, seeing that there is not currently a PHYSICAL line (remember TT devices, ordinary serial lines?) attached to the PTY, is sends a request to a detached job named the "PTY Server".
The PTY server's job is to connect PTYs and TTYs. All its activity is controlled by the file SY:SERVICES.PTY. This may instruct it that it needs to execute a TPL script to dial a phone number and log onto a remote system before connecting the pseudo and real terminals together. Meanwhile, the TCP/IP code is impatiently waiting for that packet to be transmitted. In fact, systems using phonenet often have to increase the value of TCP_CONNTIME, which controls how long TCP/IP will wait for a connection to be established.
When the PTY server has successfully done its job, it signals the PTY driver code in the operating system that the PTY is connected to a TTY. Now the request to transmit that first character of the packet is made again, and this time the PTY driver is content. It has a real physical device associated with the PTY, and passes the request straight into that driver. That driver might be the driver for the ordinary COM ports, a Maxpeed, and so on.
When characters are received from the other end of the connection, they are processed by the driver for the physical line and passed into the operating system. TSX quickly realizes this line is connected to a PTY and sends the character directly into the networking code.
So, PTY lines are sort of like virtual terminals in that they don't physically exist, but the point is that their purpose is to be a TCP/IP interface that gets connected to a physical line somehow.
The other type of use for PTY lines is pass-through SLIP and PPP. Users connecting to a TSX system who want to go into pass-through networking mode send a request to the PTY server, who finds them an available PTY line and hooks their physical line up to the network code.
We have nearly exhausted the various types of terminals which exist in TSX but we have one more to go: reverse telnet lines. Reverse telnet provides a mechanism for printing to printers which are attached to remote terminal servers. These terminal servers have multiple serial lines connected to them and work in two directions for two different purposes. First, people connect serial terminals to them and access a TSX system through them. When they do this, the terminal server creates a telnet connection into the TSX box, typically over a very wide area network. For example, people in Toronto may have an 8 line terminal server with 5 serial terminals connected to it. When the log into the terminal server, it creates a telnet connection over the internet to the TSX system they are trying to access, which happens to be at corporate headquarters in Quebec.
What about the other 3 lines on the terminal server, are they just spares? No, they have printers attached to them. If the TSX system can somehow manage to initiate a telnet connection back to the terminal server, specifying the ip address associated with those lines that have the printers attached to them, it can cause the customer's invoices to be printed on the printer. But how would you do this? The only way to make a telnet connection out of a TSX system is to use the telnet program, right?
This is where the reverse telnet lines come in. By genning in reverse telnet lines (which, not shockingly, are not really physical terminals, they are only exist in the computer's memory), we create a device which the spooler can open and send data to. As far as the spooler is concerned, it's opening an ordinary physical serial line and printing to a serial printer that's right there in the room with it. Little does the spooler know that the reverse telnet driver in the kernel sees that first character and discovers to its horror that the line is not currently connected to anything. Now the PTY driver would have asked the PTY server to cross connect the line to a physical line, but that's not what we want here. What we want is to open a socket connection to the telnet port on some remote system -- well, on some remote terminal server -- and send the characters through that socket. So that's what the reverse telnet driver does; it makes the connection, and from that point on, the ordinary driver for telnet lines (remember TTN lines for incoming telnet connections?) is used to send the characters to the remote telnet client. So, the spooler thinks it is writing to a physical serial port, and the telnet code thinks it's sending data out to some guy's telnet session, but the data is really going to an HP Laserjet printer attached to the terminal server in Toronto.
You may have noticed that a common theme is that various components of the operating system are fooled into believing something that's not true. TSX thinks those virtual terminals are real, so it runs jobs on them and allows them to become TCP/IP interfaces. The network code thinks that PTY's are real SLIP or PPP lines, so it allows data to flow through them without even knowing that the PTY Server's out there connecting and disconnecting network interfaces from real lines. The spooler thinks it's talking to a serial line and the telnet code thinks it's talking to a person. You have to keep all these secrets safe!