Telnet Protocol specification(3)

　　TRANSMISSION OF DATA

　　Although a TELNET connection through the network is intrinsically　full duplex, the NVT is to be viewed as a half-duplex device　operating in a line-buffered mode. That is, unless and until　options are negotiated to the contrary, the following default　conditions pertain to the transmission of data over the TELNET　connection:

　　1) Insofar as the availability of local buffer space permits,　data should be accumulated in the Host where it is generated　until a complete line of data is ready for transmission, or　until some locally-defined explicit signal to transmit occurs.

    　This signal could be generated either by a process or by a　human user.

　　The motivation for this rule is the high cost, to some Hosts,　of processing network input interrupts, coupled with the　default NVT specification that "echoes" do not traverse the　network. Thus, it is reasonable to buffer some amount of data　at its source. Many systems take some processing action at the　end of each input line (even line printers or card punches　frequently tend to work this way), so the transmission should　be triggered at the end of a line. On the other hand, a user　or process may sometimes find it necessary or desirable to　provide data which does not terminate at the end of a line;　therefore implementers are cautioned to provide methods of　locally signaling that all buffered data should be transmitted　immediately.

　　2) When a process has completed sending data to an NVT printer　and has no queued input from the NVT keyboard for further　processing (i.e., when a process at one end of a TELNET　connection cannot proceed without input from the other end),　the process must transmit the TELNET Go Ahead (GA) command.

　　This rule is not intended to require that the TELNET GA command　be sent from a terminal at the end of each line, since server　Hosts do not normally require a special signal (in addition to　end-of-line or other locally-defined characters) in order to　commence processing. Rather, the TELNET GA is designed to help　a user's local Host operate a physically half duplex terminal　which has a "lockable" keyboard such as the IBM 2741. A　description of this type of terminal may help to explain the　proper use of the GA command.

　　The terminal-computer connection is always under control of　either the user or the computer. Neither can unilaterally　seize control from the other; rather the controlling end must　relinguish its control explicitly. At the terminal end, the　hardware is constructed so as to relinquish control each time　that a "line" is terminated (i.e., when the "New Line" key is　typed by the user). When this occurs, the attached (local)　computer processes the input data, decides if output should be　generated, and if not returns control to the terminal. If　output should be generated, control is retained by the computer　until all output has been transmitted.

　　The difficulties of using this type of terminal through the　network should be obvious. The "local" computer is no longer　able to decide whether to retain control after seeing an　end-of-line signal or not; this decision can only be made by　the "remote" computer which is processing the data. Therefore,　the TELNET GA command provides a mechanism whereby the "remote"　(server) computer can signal the "local" (user) computer that　it is time to pass control to the user of the terminal. It　should be transmitted at those times, and only at those times,　when the user should be given control of the terminal. Note　that premature transmission of the GA command may result in the　blocking of output, since the user is likely to assume that the　transmitting system has paused, and therefore he will fail to　turn the line around manually.

　　The foregoing, of course, does not apply to the user-to-server　direction of communication. In this direction, GAs may be sent at　any time, but need not ever be sent. Also, if the TELNET　connection is being used for process-to-process communication, GAs　need not be sent in either direction. Finally, for　terminal-to-terminal communication, GAs may be required in　neither, one, or both directions. If a Host plans to support　terminal-to-terminal communication it is suggested that the Host　provide the user with a means of manually signaling that it is　time for a GA to be sent over the TELNET connection; this,　however, is not a requirement on the implementer of a TELNET　process.