Second thoughts on Telnet Go-Ahead(2)

　　The user Telnet transmits this text line over the connection;　however, due to insufficient allocation or other conditions, the　text actually gets packaged up and sent as two or more separate　messages, which arrive at the server host in the correct order but　separated by some amount of time.

　　The server Telnet passes the contents of the first message to the　appropriate process, which reads the partial text line and　immediately blocks for further input. At this moment (assuming　the second message hasn't arrived yet), the server telnet, in　accordance with the Protocol, sends back a GA command.

　　The rest of the text then arrives in response, the server process　may generate a large volume of output. Meanwhile, however, the GA　command has caused the user's keyboard to become unlocked and　computer output thereby blocked. Hence we have a deadlock, which　will be resolved only when the user recognizes what has happened　and (manually) gives control back to the computer.

　　Of course, this particular problem is avoided if the Telnet protocol　is modified to specify that the server Telnet will transmit GA only　if the server process is blocked for input AND the most recent　character passed to that process was end-of-line.

　　I claim that this solution is bad in principle because it assumes　too much knowledge on the part of the serving host as to what　constitutes "end-of-line" in the using host.

　　Furthermore, the Protocol explicitly (and quite rightly) specifies　that the user Telnet should provide some means by which a user may　signal that all buffered text should be transmitted immediately,　without its being terminated by end-of-line.

　　One must conclude, then, that in general the server Telnet has no　precise way of knowing when it should send GA commands.

　　IMPLEMENTATION PROBLEMS

　　The foregoing analysis illustrates the problems that arise with the　GA mechanism in communication between servers and users whose normal　mode of operation is half-duplex, line-at-a-time. When we turn to　hosts that provide full-duplex service, such as the PDP-10s and many　other hosts on the Network, the problems are much more severe.

　　This is particularly true of operating system such as Tenex that　exercise such tight control over terminal behavior that they　prefer to operate in server echoing, character-at-a-time mode.

　　This will probably become less necessary as protocols such as　Remote Controlled transmission and Echoing Option come into　general use, enabling servers to regulate echoing and break　character classes in user Telnets.

　　Even in hosts such as 10/50 systems that provide reasonable service　to line-at-a-time users for most subsystems (e.g. excluding DDT and　　TECO), GA is impossible to implement correctly. This is true for　several reasons.

　　First, there are a number of subsystems that never block for terminal　input but rather poll for it or accept it on an interrupt basis. In　the absence of typein, such processes go on to do other tasks,　possibly generating terminal output.

　　Processes of this sort come immediately to mind. The user telnet,　FTP, and RJE programs are implemented in this fashion by almost　all hosts. 10/50 has a subsystem called OPSER, used to control　multiple independent subjobs from a single terminal.

　　Since these programs never block for input, GA commands will never　be sent by the server Telnet in such cases even though the　processes are prepared to accept terminal input at any time.

　　Second, there is not necessarily a one-to-one relationship between　processes and terminals, as seems to be assumed by the Telnet

　　Protocol specification.

　　For example, in Tenex one process may be blocked for terminal　input while another process is generating output to the same　terminal. (Such processes are typically parallel forks of the　same job).

　　Third, there is the possibility of inter-terminal links, such as are　provided in many systems.

　　By this I do not mean special Telnet connections established　between a pair of NVTs for the express purpose of terminal-to-terminal communication, as is suggested on page 9 of the Protocol　specification. Rather, I am referring to facilities such as the　Tenex LINK facility, in which any number and any mixture of local　and Network terminals and processes may have their input and　output streams linked together in arbitrarily complex ways.

　　Clearly the GA mechanism will fall flat on its face in this case.　Also, the notion that one user of an inter-terminal link should　have to "manually signal that it is time for a GA to be sent over　the Telnet connection" in order to unblock another user's keyboard　offends me to no end.

　　Finally, most systems provide means by which system personnel and　processes may broadcast important messages to all terminals (e.g.　SEND ALL in 10/50, NOTIFY in Tenex). Clearly such asynchronous　messages will be blocked by a half-duplex terminal that has been　irrevocably placed in the typein state by a previous GA.

　　This strikes me as such an obvious problem that I am forced to　wonder how half-duplex hosts handle it even for their local　terminals.

　　[ This RFCwas put into machine readable form for entry ]

　　[ into the online RFCarchives by Mirsad Todorovac 5/98 ]