reactos/apps/utils/net/telnet/nvt.cpp

   1 /* $Id: nvt.cpp,v 1.1 2001/01/27 22:38:43 ea Exp $
   2  *
   3  * FILE       : nvt.cpp
   4  * AUTHOR     : unknown (sources found on www.telnet.org)
   5  * PROJECT    : ReactOS Operating System
   6  * DESCRIPTION: telnet client for the W32 subsystem
   7  * DATE       : 2001-01-21
   8  * REVISIONS
   9  *      2001-02-21 ea   Modified to compile under 0.0.16 src tree
  10  */
  11 ///////////////////////////////////////////////////////////////////////////////
  12 //
  13 // file: nvt.cpp
  14 //
  15 // purpose: Provides the "bare bones" telnet "Network Virtual Terminal"
  16 //          that is our default. We only se a more capable terminal, if
  17 //          properly requested via the telnet option.
  18 //
  19 // refrence: The following excerpt from rfc 854
  20 //
  21 ///////////////////////////////////////////////////////////////////////////////
  22 /*
  23 THE NETWORK VIRTUAL TERMINAL
  24
  25    The Network Virtual Terminal (NVT) is a bi-directional character
  26    device.  The NVT has a printer and a keyboard.  The printer responds
  27    to incoming data and the keyboard produces outgoing data which is
  28    sent over the TELNET connection and, if "echoes" are desired, to the
  29    NVT's printer as well.  "Echoes" will not be expected to traverse the
  30    network (although options exist to enable a "remote" echoing mode of
  31    operation, no host is required to implement this option).  The code
  32    set is seven-bit USASCII in an eight-bit field, except as modified
  33    herein.  Any code conversion and timing considerations are local
  34    problems and do not affect the NVT.
  35
  36    TRANSMISSION OF DATA
  37
  38       Although a TELNET connection through the network is intrinsically
  39       full duplex, the NVT is to be viewed as a half-duplex device
  40       operating in a line-buffered mode.  That is, unless and until
  41       options are negotiated to the contrary, the following default
  42       conditions pertain to the transmission of data over the TELNET
  43       connection:
  44
  45          1)  Insofar as the availability of local buffer space permits,
  46          data should be accumulated in the host where it is generated
  47          until a complete line of data is ready for transmission, or
  48          until some locally-defined explicit signal to transmit occurs.
  49          This signal could be generated either by a process or by a
  50          human user.
  51
  52          The motivation for this rule is the high cost, to some hosts,
  53          of processing network input interrupts, coupled with the
  54          default NVT specification that "echoes" do not traverse the
  55          network.  Thus, it is reasonable to buffer some amount of data
  56          at its source.  Many systems take some processing action at the
  57          end of each input line (even line printers or card punches
  58          frequently tend to work this way), so the transmission should
  59          be triggered at the end of a line.  On the other hand, a user
  60          or process may sometimes find it necessary or desirable to
  61          provide data which does not terminate at the end of a line;
  62          therefore implementers are cautioned to provide methods of
  63          locally signaling that all buffered data should be transmitted
  64          immediately.
  65
  66          2)  When a process has completed sending data to an NVT printer
  67          and has no queued input from the NVT keyboard for further
  68          processing (i.e., when a process at one end of a TELNET
  69          connection cannot proceed without input from the other end),
  70          the process must transmit the TELNET Go Ahead (GA) command.
  71
  72          This rule is not intended to require that the TELNET GA command
  73          be sent from a terminal at the end of each line, since server
  74          hosts do not normally require a special signal (in addition to
  75          end-of-line or other locally-defined characters) in order to
  76          commence processing.  Rather, the TELNET GA is designed to help
  77          a user's local host operate a physically half duplex terminal
  78          which has a "lockable" keyboard such as the IBM 2741.  A
  79          description of this type of terminal may help to explain the
  80          proper use of the GA command.
  81
  82          The terminal-computer connection is always under control of
  83          either the user or the computer.  Neither can unilaterally
  84          seize control from the other; rather the controlling end must
  85          relinguish its control explicitly.  At the terminal end, the
  86          hardware is constructed so as to relinquish control each time
  87          that a "line" is terminated (i.e., when the "New Line" key is
  88          typed by the user).  When this occurs, the attached (local)
  89          computer processes the input data, decides if output should be
  90          generated, and if not returns control to the terminal.  If
  91          output should be generated, control is retained by the computer
  92          until all output has been transmitted.
  93
  94          The difficulties of using this type of terminal through the
  95          network should be obvious.  The "local" computer is no longer
  96          able to decide whether to retain control after seeing an
  97          end-of-line signal or not; this decision can only be made by
  98          the "remote" computer which is processing the data.  Therefore,
  99          the TELNET GA command provides a mechanism whereby the "remote"
 100          (server) computer can signal the "local" (user) computer that
 101          it is time to pass control to the user of the terminal.  It
 102          should be transmitted at those times, and only at those times,
 103          when the user should be given control of the terminal.  Note
 104          that premature transmission of the GA command may result in the
 105          blocking of output, since the user is likely to assume that the
 106          transmitting system has paused, and therefore he will fail to
 107          turn the line around manually.
 108
 109       The foregoing, of course, does not apply to the user-to-server
 110       direction of communication.  In this direction, GAs may be sent at
 111       any time, but need not ever be sent.  Also, if the TELNET
 112       connection is being used for process-to-process communication, GAs
 113       need not be sent in either direction.  Finally, for
 114       terminal-to-terminal communication, GAs may be required in
 115       neither, one, or both directions.  If a host plans to support
 116       terminal-to-terminal communication it is suggested that the host
 117       provide the user with a means of manually signaling that it is
 118       time for a GA to be sent over the TELNET connection; this,
 119       however, is not a requirement on the implementer of a TELNET
 120       process.
 121
 122       Note that the symmetry of the TELNET model requires that there is
 123       an NVT at each end of the TELNET connection, at least
 124       conceptually.
 125 *//*
 126
 127    THE NVT PRINTER AND KEYBOARD
 128
 129       The NVT printer has an unspecified carriage width and page length
 130       and can produce representations of all 95 USASCII graphics (codes
 131       32 through 126).  Of the 33 USASCII control codes (0 through 31
 132       and 127), and the 128 uncovered codes (128 through 255), the
 133       following have specified meaning to the NVT printer:
 134
 135          NAME                  CODE         MEANING
 136
 137          NULL (NUL)              0      No Operation
 138          Line Feed (LF)         10      Moves the printer to the
 139                                         next print line, keeping the
 140                                         same horizontal position.
 141          Carriage Return (CR)   13      Moves the printer to the left
 142                                         margin of the current line.
 143
 144          In addition, the following codes shall have defined, but not
 145          required, effects on the NVT printer.  Neither end of a TELNET
 146          connection may assume that the other party will take, or will
 147          have taken, any particular action upon receipt or transmission
 148          of these:
 149
 150          BELL (BEL)              7      Produces an audible or
 151                                         visible signal (which does
 152                                         NOT move the print head).
 153          Back Space (BS)         8      Moves the print head one
 154                                         character position towards
 155                                         the left margin.
 156          Horizontal Tab (HT)     9      Moves the printer to the
 157                                         next horizontal tab stop.
 158                                         It remains unspecified how
 159                                         either party determines or
 160                                         establishes where such tab
 161                                         stops are located.
 162          Vertical Tab (VT)       11     Moves the printer to the
 163                                         next vertical tab stop.  It
 164                                         remains unspecified how
 165                                         either party determines or
 166                                         establishes where such tab
 167                                         stops are located.
 168          Form Feed (FF)          12     Moves the printer to the top
 169                                         of the next page, keeping
 170                                         the same horizontal position.
 171
 172       All remaining codes do not cause the NVT printer to take any
 173       action.
 174
 175       The sequence "CR LF", as defined, will cause the NVT to be
 176       positioned at the left margin of the next print line (as would,
 177       for example, the sequence "LF CR").  However, many systems and
 178       terminals do not treat CR and LF independently, and will have to
 179       go to some effort to simulate their effect.  (For example, some
 180       terminals do not have a CR independent of the LF, but on such
 181       terminals it may be possible to simulate a CR by backspacing.)
 182       Therefore, the sequence "CR LF" must be treated as a single "new
 183       line" character and used whenever their combined action is
 184       intended; the sequence "CR NUL" must be used where a carriage
 185       return alone is actually desired; and the CR character must be
 186       avoided in other contexts.  This rule gives assurance to systems
 187       which must decide whether to perform a "new line" function or a
 188       multiple-backspace that the TELNET stream contains a character
 189       following a CR that will allow a rational decision.
 190
 191          Note that "CR LF" or "CR NUL" is required in both directions
 192          (in the default ASCII mode), to preserve the symmetry of the
 193          NVT model.  Even though it may be known in some situations
 194          (e.g., with remote echo and suppress go ahead options in
 195          effect) that characters are not being sent to an actual
 196          printer, nonetheless, for the sake of consistency, the protocol
 197          requires that a NUL be inserted following a CR not followed by
 198          a LF in the data stream.  The converse of this is that a NUL
 199          received in the data stream after a CR (in the absence of
 200          options negotiations which explicitly specify otherwise) should
 201          be stripped out prior to applying the NVT to local character
 202          set mapping.
 203
 204       The NVT keyboard has keys, or key combinations, or key sequences,
 205       for generating all 128 USASCII codes.  Note that although many
 206       have no effect on the NVT printer, the NVT keyboard is capable of
 207       generating them.
 208
 209       In addition to these codes, the NVT keyboard shall be capable of
 210       generating the following additional codes which, except as noted,
 211       have defined, but not reguired, meanings.  The actual code
 212       assignments for these "characters" are in the TELNET Command
 213       section, because they are viewed as being, in some sense, generic
 214       and should be available even when the data stream is interpreted
 215       as being some other character set.
 216
 217       Synch
 218
 219          This key allows the user to clear his data path to the other
 220          party.  The activation of this key causes a DM (see command
 221          section) to be sent in the data stream and a TCP Urgent
 222          notification is associated with it.  The pair DM-Urgent is to
 223          have required meaning as defined previously.
 224
 225       Break (BRK)
 226
 227          This code is provided because it is a signal outside the
 228          USASCII set which is currently given local meaning within many
 229          systems.  It is intended to indicate that the Break Key or the
 230          Attention Key was hit.  Note, however, that this is intended to
 231          provide a 129th code for systems which require it, not as a
 232          synonym for the IP standard representation.
 233
 234       Interrupt Process (IP)
 235
 236          Suspend, interrupt, abort or terminate the process to which the
 237          NVT is connected.  Also, part of the out-of-band signal for
 238          other protocols which use TELNET.
 239
 240       Abort Output (AO)
 241
 242          Allow the current process to (appear to) run to completion, but
 243          do not send its output to the user.  Also, send a Synch to the
 244          user.
 245
 246       Are You There (AYT)
 247
 248          Send back to the NVT some visible (i.e., printable) evidence
 249          that the AYT was received.
 250
 251       Erase Character (EC)
 252
 253          The recipient should delete the last preceding undeleted
 254          character or "print position" from the data stream.
 255
 256       Erase Line (EL)
 257
 258          The recipient should delete characters from the data stream
 259          back to, but not including, the last "CR LF" sequence sent over
 260          the TELNET connection.
 261
 262       The spirit of these "extra" keys, and also the printer format
 263       effectors, is that they should represent a natural extension of
 264       the mapping that already must be done from "NVT" into "local".
 265       Just as the NVT data byte 68 (104 octal) should be mapped into
 266       whatever the local code for "uppercase D" is, so the EC character
 267       should be mapped into whatever the local "Erase Character"
 268       function is.  Further, just as the mapping for 124 (174 octal) is
 269       somewhat arbitrary in an environment that has no "vertical bar"
 270       character, the EL character may have a somewhat arbitrary mapping
 271       (or none at all) if there is no local "Erase Line" facility.
 272       Similarly for format effectors:  if the terminal actually does
 273       have a "Vertical Tab", then the mapping for VT is obvious, and
 274       only when the terminal does not have a vertical tab should the
 275
 276 */
 277
 278 #include <winsock.h>
 279 #include <windows.h>
 280
 281 #include "telnet.h"
 282
 283 void nvt(SOCKET server,unsigned char data)
 284 {
 285   DWORD z;
 286   switch(data)
 287   {
 288   case 0:  //eat null codes.
 289     break;
 290   default: //Send all else to the console.
 291     WriteConsole(StandardOutput, & data, 1, & z, NULL);
 292     break;
 293   }
 294 }
 295
 296 /* EOF */