rfc596.Second Thoughts on Telnet Go-Ahead

1、rfc596.second thoughts on telnet go-ahead rfc文檔 network working group e. taftrequest for comments: 596 parc-maxcnic: 15372 8 december 1973 second thoughts on telnet go-ahead introduction in this rfc we present objections to the requirement that hosts implement the telnet go-ahead (ga) command, as sp

2、ecified in the telnet protocol specification (nic #15372). the thrust of these objections is in three major directions: 1. the ga mechanism is esthetically unappealing, both to myself and to many other people i have talked to. i shall attempt to describe why this is so. 2. as specified in the protoc

3、ol, ga will not, in general, work; i.e. it will not serve its intended purpose unless hosts make various unwarranted assumptions about how other hosts operate. 3. ga is impossible for most hosts to implement correctly in all cases. this is certainly true of the pdp-10 operating systems with which i

4、am familiar (10/50 and tenex). the purpose of this rfc is to advocate either complete removal of the ga mechanism or relegating it to the status of a negotiated option whose default state is that it be suppressed. terminology half-duplex is a two-way communication discipline in which transmission ta

5、kes place in only one direction at a time and the receiving party is constrained not to transmit until the transmitting party has explicitly given up control of the communication path (turned the line around). this definition is distinct from a common (but incorrect) use of the terms half-duplex and

6、 full-duplex to designate local and remote character echoing. reverse break is a means by which a computer connected to a terminal by a half-duplex path may regain control of the path for further typeout after previously having relinquished it. taft page 1 rfc文檔 this is the complement of the break o

7、r attention mechanism, implemented by all half-duplex terminals, by means of which the user may gain control of the line while it is in use by the computer.esthetic objections to ga one assumption that permeates the telnet protocol specification (and is explicitly stated on page 7) is that the norma

8、l mode of communication between computers and terminals is half-duplex, line- at-a-time. while historically this is partially true, it is also clear, both within the arpa network community and elsewhere, that the trend is toward highly interactive man-machine communication systems which are difficul

9、t to implement under half-duplex communication disciplines. the ga mechanism is an attempt to solve a specific problem, that of switching control between computer and user in a subset of those hosts utilizing ibm 2741 or equivalent terminals. i say a subset because in fact the problem arises only in

10、 the case of tips from 2741s (with reverse break); from what experience i have had, i think the tip does a very good job of turning the line around at the right moments. (i am told this is also the case at multics). given the trend toward more interactive communication, and given the fact that termi

11、nals on the network requiring a go-ahead mechanism are a distinct minority of all terminals, i think we should be reluctant to burden our protocols with kludges that are so clearly a concession to obsolete design. i have little doubt that before long somebody (if not ibm) will produce a full-duplex

12、2741-like terminal (indeed, perhaps it has already been done). there is an obvious need for a terminal with selectric quality keyboard and hard-copy better suited to interactive applications (i.e. full-duplex). as a more practical consideration, it makes little sense to have the default state of the

13、 ga option be the one that benefits the least number of hosts and terminals. there is no question that most parties to telnet communication will immediately negotiate to suppress ga. to do otherwise will double the amount of network traffic generated by character-at-a- time typein, and will increase

14、 it by a non-negligible amount even for a line-at-a-time typein. it strikes me as worthwhile to minimize the number of such necessary option negotiations, especially in view of the large number of tips and mini-hosts on the network. many such hosts taft page 2 rfc文檔 must, due to resource constraints

15、, implement only a limited subset of the available options. it follows, then, that the default state of all options should be the one most hosts will be willing to use. why ga wont work we now show that a server processs being blocked on input (as specified in the protocol) is not itself a sufficien

16、t condition for sending out ga. this is due to the fact that the user telnet has no control over the packaging of a line of information sent to the server; rather, this is a function of the ncp, which must observe constraints such as allocation and buffering. consider the following example: a user t

17、ypes a line of text, which is buffered by his hosts user telnet until he signals end-of-line. his keyboard then becomes locked (this being the behavior of half-duplex terminals while the computer has control of the line), and stays locked in anticipation of the servers eventual response and subseque

18、nt ga command. 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

19、 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 hasnt arrived yet), the server telnet, in accordance with the protocol, sends back a g

20、a 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 users keyboard to become unlocked and computer output thereby blocked. hence we have a deadlock, which will be resolved only when the

21、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 passe

22、d to that process was end-of-line. taft page 3 rfc文檔 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

23、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. implementa

24、tion 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

25、 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

26、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

27、 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 termin

28、al 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,

29、 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. taft page 4 rfc文檔 second, there is not necessarily a one-to-one relationship between processes and terminals, as seems to be assumed by the telnet protocol

30、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 facilit