418.htm

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

   All TELNET commands consist of at least a two byte sequence:  the <br>
   "Interpret as Command" (IAC) escape character followed by the code <br>
   for the command.  The commands dealing with option negotiation are <br>
   three byte sequences, the third byte being the code for the option <br>
   referenced.  This format was chosen so that as more comprehensive use <br>
   of the "data space" is made -- by negotiations from the basic NVT, of <br>
   course -- collisions of data bytes with reserved command values will <br>
   be minimized, all such collisions requiring the inconvenience, and <br>
Postel & Reynolds                                              [Page 13] <br>
  <br>
RFC 854                                                         May 1983 <br>
   inefficiency, of "escaping" the data bytes into the stream.  With the <br>
   current set-up, only the IAC need be doubled to be sent as data, and <br>
   the other 255 codes may be passed transparently. <br>
   The following are the defined TELNET commands.  Note that these codes <br>
   and code sequences have the indicated meaning only when immediately <br>
   preceded by an IAC. <br>
      NAME               CODE              MEANING <br>
      SE                  240    End of subnegotiation parameters. <br>
      NOP                 241    No operation. <br>
      Data Mark           242    The data stream portion of a Synch. <br>

                                 This should always be accompanied <br>
                                 by a TCP Urgent notification. <br>
      Break               243    NVT character BRK. <br>
      Interrupt Process   244    The function IP. <br>
      Abort output        245    The function AO. <br>
      Are You There       246    The function AYT. <br>
      Erase character     247    The function EC. <br>
      Erase Line          248    The function EL. <br>
      Go ahead            249    The GA signal. <br>
      SB                  250    Indicates that what follows is <br>
                                 subnegotiation of the indicated <br>
                                 option. <br>
      WILL (option code)  251    Indicates the desire to begin <br>
                                 performing, or confirmation that <br>
                                 you are now performing, the <br>
                                 indicated option. <br>
      WON'T (option code) 252    Indicates the refusal to perform, <br>
                                 or continue performing, the <br>
                                 indicated option. <br>
      DO (option code)    253    Indicates the request that the <br>
                                 other party perform, or <br>
                                 confirmation that you are expecting <br>

                                 the other party to perform, the <br>
                                 indicated option. <br>
      DON'T (option code) 254    Indicates the demand that the <br>
                                 other party stop performing, <br>
                                 or confirmation that you are no <br>
                                 longer expecting the other party <br>
                                 to perform, the indicated option. <br>
      IAC                 255    Data Byte 255. <br>
Postel & Reynolds                                              [Page 14] <br>
  <br>
RFC 854                                                         May 1983 <br>
CONNECTION ESTABLISHMENT <br>
   The TELNET TCP connection is established between the user's port U <br>
   and the server's port L.  The server listens on its well known port L <br>
   for such connections.  Since a TCP connection is full duplex and <br>
   identified by the pair of ports, the server can engage in many <br>
   simultaneous connections involving its port L and different user <br>
   ports U. <br>
   Port Assignment <br>
      When used for remote user access to service hosts (i.e., remote <br>
      terminal access) this protocol is assigned server port 23 <br>
      (27 octal).  That is L=23. <br>

Postel & Reynolds                                              [Page 15] <br>
  <br>
  <br>
  <br>
Network Working Group                                          J. Postel <br>
Request for Comments: 855                                    J. Reynolds <br>
                                                                     ISI <br>
Obsoletes: NIC 18640                                            May 1983 <br>
                      TELNET OPTION SPECIFICATIONS <br>
This RFC specifies a standard for the ARPA Internet community.  Hosts on <br>
the ARPA Internet are expected to adopt and implement this standard. <br>
The intent of providing for options in the TELNET Protocol is to permit <br>
hosts to obtain more elegant solutions to the problems of communication <br>
between dissimilar devices than is possible within the framework <br>
provided by the Network Virtual Terminal (NVT).  It should be possible <br>
for hosts to invent, test, or discard options at will.  Nevertheless, it <br>
is envisioned that options which prove to be generally useful will <br>
eventually be supported by many hosts; therefore it is desirable that <br>
options should be carefully documented and well publicized.  In <br>
addition, it is necessary to insure that a single option code is not <br>
used for several different options. <br>
This document specifies a method of option code assignment and standards <br>

for documentation of options.  The individual responsible for assignment <br>
of option codes may waive the requirement for complete documentation for <br>
some cases of experimentation, but in general documentation will be <br>
required prior to code assignment.  Options will be publicized by <br>
publishing their documentation as RFCs; inventors of options may, of <br>
course, publicize them in other ways as well. <br>
   Option codes will be assigned by: <br>
      Jonathan B. Postel <br>
      University of Southern California <br>
      Information Sciences Institute (USC-ISI) <br>
      4676 Admiralty Way <br>
      Marina Del Rey, California 90291 <br>
      [phone] <br>
      Mailbox = POSTEL@USC-ISIF <br>
Documentation of options should contain at least the following sections: <br>
   Section 1 - Command Name and Option Code <br>
   Section 2 - Command Meanings <br>
      The meaning of each possible TELNET command relevant to this <br>
      option should be described.  Note that for complex options, where <br>
Postel & Reynolds                                               [Page 1] <br>
  <br>
RFC 855                                                         May 1983 <br>

      "subnegotiation" is required, there may be a larger number of <br>
      possible commands.  The concept of "subnegotiation" is described <br>
      in more detail below. <br>
   Section 3 - Default Specification <br>
      The default assumptions for hosts which do not implement, or use, <br>
      the option must be described. <br>
   Section 4 - Motivation <br>
      A detailed explanation of the motivation for inventing a <br>
      particular option, or for choosing a particular form for the <br>
      option, is extremely helpful to those who are not faced (or don't <br>
      realize that they are faced) by the problem that the option is <br>
      designed to solve. <br>
   Section 5 - Description (or Implementation Rules) <br>
      Merely defining the command meanings and providing a statement of <br>
      motivation are not always sufficient to insure that two <br>
      implementations of an option will be able to communicate. <br>
      Therefore, a more complete description should be furnished in most <br>
      cases.  This description might take the form of text, a sample <br>
      implementation, hints to implementers, etc. <br>
A Note on "Subnegotiation" <br>
   Some options will require more information to be passed between hosts <br>
   than a single option code.  For example, any option which requires a <br>

   parameter is such a case.  The strategy to be used consists of two <br>
   steps:  first, both parties agree to "discuss" the parameter(s) and, <br>
   second, the "discussion" takes place. <br>
   The first step, agreeing to discuss the parameters, takes place in <br>
   the normal manner; one party proposes use of the option by sending a <br>
   DO (or WILL) followed by the option code, and the other party accepts <br>
   by returning a WILL (or DO) followed by the option code.  Once both <br>
   parties have agreed to use the option, subnegotiation takes place by <br>
   using the command SB, followed by the option code, followed by the <br>
   parameter(s), followed by the command SE.  Each party is presumed to <br>
   be able to parse the parameter(s), since each has indicated that the <br>
   option is supported (via the initial exchange of WILL and DO).  On <br>
   the other hand, the receiver may locate the end of a parameter string <br>
   by searching for the SE command (i.e., the string IAC SE), even if <br>
   the receiver is unable to parse the parameters.  Of course, either <br>
   party may refuse to pursue further subnegotiation at any time by <br>
   sending a WON'T or DON'T to the other party. <br>
Postel & Reynolds                                               [Page 2] <br>
  <br>
RFC 855                                                         May 1983 <br>
   Thus, for option "ABC", which requires subnegotiation, the formats of <br>
   the TELNET commands are: <br>

      IAC WILL ABC <br>
         Offer to use option ABC (or favorable acknowledgment of other <br>
         party's request) <br>
      IAC DO ABC <br>
         Request for other party to use option ABC (or favorable <br>
         acknowledgment of other party's offer) <br>
      IAC SB ABC <parameters> IAC SE <br>
         One step of subnegotiation, used by either party. <br>
   Designers of options requiring "subnegotiation" must take great care <br>
   to avoid unending loops in the subnegotiation process.  For example, <br>
   if each party can accept any value of a parameter, and both parties <br>
   suggest parameters with different values, then one is likely to have <br>
   an infinite oscillation of "acknowledgments" (where each receiver <br>
   believes it is only acknowledging the new proposals of the other). <br>
   Finally, if parameters in an option "subnegotiation" include a byte <br>
   with a value of 255, it is necessary to double this byte in <br>
   accordance the general TELNET rules. <br>
Postel & Reynolds                                               [Page 3] <br>
  <br>
  <br>
  <br>
-- <br>

指点江山，激扬文字，粪土当年万户侯。 <br>
  <br>
  <br>
※ 修改:·hellow 於 Nov  5 09:35:44 修改本文·[FROM:  166.111.161.69] <br>
※ 来源:·BBS 水木清华站 smth.org·[FROM: 166.111.161.69] <br>
</small><hr>
<p align="center">[<a href="嵌入式系统.htm">回到开始</a>][<a href="398.htm">上一层</a>][<a href="419.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>