418.htm

pcb设计资料初学者难得的入门资料包含工厂制作过程

  <br>
  <br>
RFC 854                                                         May 1983 <br>
      options are negotiated to the contrary, the following default <br>
      conditions pertain to the transmission of data over the TELNET <br>
      connection: <br>
         1)  Insofar as the availability of local buffer space permits, <br>
         data should be accumulated in the host where it is generated <br>
         until a complete line of data is ready for transmission, or <br>
         until some locally-defined explicit signal to transmit occurs. <br>
         This signal could be generated either by a process or by a <br>
         human user. <br>
         The motivation for this rule is the high cost, to some hosts, <br>
         of processing network input interrupts, coupled with the <br>
         default NVT specification that "echoes" do not traverse the <br>
         network.  Thus, it is reasonable to buffer some amount of data <br>
         at its source.  Many systems take some processing action at the <br>
         end of each input line (even line printers or card punches <br>
         frequently tend to work this way), so the transmission should <br>
         be triggered at the end of a line.  On the other hand, a user <br>
         or process may sometimes find it necessary or desirable to <br>
         provide data which does not terminate at the end of a line; <br>
         therefore implementers are cautioned to provide methods of <br>
         locally signaling that all buffered data should be transmitted <br>

         immediately. <br>
         2)  When a process has completed sending data to an NVT printer <br>
         and has no queued input from the NVT keyboard for further <br>
         processing (i.e., when a process at one end of a TELNET <br>
         connection cannot proceed without input from the other end), <br>
         the process must transmit the TELNET Go Ahead (GA) command. <br>
         This rule is not intended to require that the TELNET GA command <br>
         be sent from a terminal at the end of each line, since server <br>
         hosts do not normally require a special signal (in addition to <br>
         end-of-line or other locally-defined characters) in order to <br>
         commence processing.  Rather, the TELNET GA is designed to help <br>
         a user's local host operate a physically half duplex terminal <br>
         which has a "lockable" keyboard such as the IBM 2741.  A <br>
         description of this type of terminal may help to explain the <br>
         proper use of the GA command. <br>
         The terminal-computer connection is always under control of <br>
         either the user or the computer.  Neither can unilaterally <br>
         seize control from the other; rather the controlling end must <br>
         relinguish its control explicitly.  At the terminal end, the <br>
         hardware is constructed so as to relinquish control each time <br>
         that a "line" is terminated (i.e., when the "New Line" key is <br>
         typed by the user).  When this occurs, the attached (local) <br>

Postel & Reynolds                                               [Page 5] <br>
  <br>
RFC 854                                                         May 1983 <br>
         computer processes the input data, decides if output should be <br>
         generated, and if not returns control to the terminal.  If <br>
         output should be generated, control is retained by the computer <br>
         until all output has been transmitted. <br>
         The difficulties of using this type of terminal through the <br>
         network should be obvious.  The "local" computer is no longer <br>
         able to decide whether to retain control after seeing an <br>
         end-of-line signal or not; this decision can only be made by <br>
         the "remote" computer which is processing the data.  Therefore, <br>
         the TELNET GA command provides a mechanism whereby the "remote" <br>
         (server) computer can signal the "local" (user) computer that <br>
         it is time to pass control to the user of the terminal.  It <br>
         should be transmitted at those times, and only at those times, <br>
         when the user should be given control of the terminal.  Note <br>
         that premature transmission of the GA command may result in the <br>
         blocking of output, since the user is likely to assume that the <br>
         transmitting system has paused, and therefore he will fail to <br>
         turn the line around manually. <br>
      The foregoing, of course, does not apply to the user-to-server <br>

      direction of communication.  In this direction, GAs may be sent at <br>
      any time, but need not ever be sent.  Also, if the TELNET <br>
      connection is being used for process-to-process communication, GAs <br>
      need not be sent in either direction.  Finally, for <br>
      terminal-to-terminal communication, GAs may be required in <br>
      neither, one, or both directions.  If a host plans to support <br>
      terminal-to-terminal communication it is suggested that the host <br>
      provide the user with a means of manually signaling that it is <br>
      time for a GA to be sent over the TELNET connection; this, <br>
      however, is not a requirement on the implementer of a TELNET <br>
      process. <br>
      Note that the symmetry of the TELNET model requires that there is <br>
      an NVT at each end of the TELNET connection, at least <br>
      conceptually. <br>
   STANDARD REPRESENTATION OF CONTROL FUNCTIONS <br>
      As stated in the Introduction to this document, the primary goal <br>
      of the TELNET protocol is the provision of a standard interfacing <br>
      of terminal devices and terminal-oriented processes through the <br>
      network.  Early experiences with this type of interconnection have <br>
      shown that certain functions are implemented by most servers, but <br>
      that the methods of invoking these functions differ widely.  For a <br>
      human user who interacts with several server systems, these <br>

      differences are highly frustrating.  TELNET, therefore, defines a <br>
      standard representation for five of these functions, as described <br>
Postel & Reynolds                                               [Page 6] <br>
  <br>
RFC 854                                                         May 1983 <br>
      below.  These standard representations have standard, but not <br>
      required, meanings (with the exception that the Interrupt Process <br>
      (IP) function may be required by other protocols which use <br>
      TELNET); that is, a system which does not provide the function to <br>
      local users need not provide it to network users and may treat the <br>
      standard representation for the function as a No-operation.  On <br>
      the other hand, a system which does provide the function to a <br>
      local user is obliged to provide the same function to a network <br>
      user who transmits the standard representation for the function. <br>
      Interrupt Process (IP) <br>
         Many systems provide a function which suspends, interrupts, <br>
         aborts, or terminates the operation of a user process.  This <br>
         function is frequently used when a user believes his process is <br>
         in an unending loop, or when an unwanted process has been <br>
         inadvertently activated.  IP is the standard representation for <br>
         invoking this function.  It should be noted by implementers <br>
         that IP may be required by other protocols which use TELNET, <br>

         and therefore should be implemented if these other protocols <br>
         are to be supported. <br>
      Abort Output (AO) <br>
         Many systems provide a function which allows a process, which <br>
         is generating output, to run to completion (or to reach the <br>
         same stopping point it would reach if running to completion) <br>
         but without sending the output to the user's terminal. <br>
         Further, this function typically clears any output already <br>
         produced but not yet actually printed (or displayed) on the <br>
         user's terminal.  AO is the standard representation for <br>
         invoking this function.  For example, some subsystem might <br>
         normally accept a user's command, send a long text string to <br>
         the user's terminal in response, and finally signal readiness <br>
         to accept the next command by sending a "prompt" character <br>
         (preceded by <CR><LF>) to the user's terminal.  If the AO were <br>
         received during the transmission of the text string, a <br>
         reasonable implementation would be to suppress the remainder of <br>
         the text string, but transmit the prompt character and the <br>
         preceding <CR><LF>.  (This is possibly in distinction to the <br>
         action which might be taken if an IP were received; the IP <br>
         might cause suppression of the text string and an exit from the <br>
         subsystem.) <br>

         It should be noted, by server systems which provide this <br>
         function, that there may be buffers external to the system (in <br>
Postel & Reynolds                                               [Page 7] <br>
  <br>
RFC 854                                                         May 1983 <br>
         the network and the user's local host) which should be cleared; <br>
         the appropriate way to do this is to transmit the "Synch" <br>
         signal (described below) to the user system. <br>
      Are You There (AYT) <br>
         Many systems provide a function which provides the user with <br>
         some visible (e.g., printable) evidence that the system is <br>
         still up and running.  This function may be invoked by the user <br>
         when the system is unexpectedly "silent" for a long time, <br>
         because of the unanticipated (by the user) length of a <br>
         computation, an unusually heavy system load, etc.  AYT is the <br>
         standard representation for invoking this function. <br>
      Erase Character (EC) <br>
         Many systems provide a function which deletes the last <br>
         preceding undeleted character or "print position"* from the <br>
         stream of data being supplied by the user.  This function is <br>
         typically used to edit keyboard input when typing mistakes are <br>
         made.  EC is the standard representation for invoking this <br>

         function. <br>
            *NOTE:  A "print position" may contain several characters <br>
            which are the result of overstrikes, or of sequences such as <br>
            <char1> BS <char2>... <br>
      Erase Line (EL) <br>
         Many systems provide a function which deletes all the data in <br>
         the current "line" of input.  This function is typically used <br>
         to edit keyboard input.  EL is the standard representation for <br>
         invoking this function. <br>
   THE TELNET "SYNCH" SIGNAL <br>
      Most time-sharing systems provide mechanisms which allow a <br>
      terminal user to regain control of a "runaway" process; the IP and <br>
      AO functions described above are examples of these mechanisms. <br>
      Such systems, when used locally, have access to all of the signals <br>
      supplied by the user, whether these are normal characters or <br>
      special "out of band" signals such as those supplied by the <br>
      teletype "BREAK" key or the IBM 2741 "ATTN" key.  This is not <br>
      necessarily true when terminals are connected to the system <br>
      through the network; the network's flow control mechanisms may <br>
      cause such a signal to be buffered elsewhere, for example in the <br>
      user's host. <br>
Postel & Reynolds                                               [Page 8] <br>

  <br>
RFC 854                                                         May 1983 <br>
      To counter this problem, the TELNET "Synch" mechanism is <br>
      introduced.  A Synch signal consists of a TCP Urgent notification, <br>
      coupled with the TELNET command DATA MARK.  The Urgent <br>
      notification, which is not subject to the flow control pertaining <br>
      to the TELNET connection, is used to invoke special handling of <br>
      the data stream by the process which receives it.  In this mode, <br>
      the data stream is immediately scanned for "interesting" signals <br>
      as defined below, discarding intervening data.  The TELNET command <br>
      DATA MARK (DM) is the synchronizing mark in the data stream which <br>