rfc1856.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 956 行 · 第 1/2 页

   message in the range of 131-139 if it wishes, but its recommended
   that the server always return ASCII describing the enoutered error.
   For example, a sample output might look like:

    >STATUS
    <931 "STATUS Command Starting"
    <STATUS= OK
    <TAG 1234 SIZE 123456
    <TAG ABCD SIZE 654321
    <932 "STATUS Command successful"

    or

    >STATUS
    <130 "Can't get STATUS right now, sorry."

    or

    >STATUS
    <931 "STATUS Command Starting"
    <STATUS= OK
    <TAG 1234 SIZE 1
    <131 "Oops, error reading TAG table, sorry."




Clark                        Informational                      [Page 9]

RFC 1856               Opstat Client-Server Model           October 1995


 3.6  The GET Command

   The GET command actually retrieves the data chosen via a previous
   SELECT command.  The GET command has the format:

    GET-CMD  ::=  GET <TAG> <TYPE>
    TAG      ::=  <ASCII-STRING>
    TYPE     ::=  1404 | <ASCII-STRING>

   If the TAG matches a previously returned TAG from a SELECT statement,
   then the previously tagged data is returned.  If the TAG is invalid
   (i.e., it hasn't been previously assigned by the server), then the
   server must return an error.  The TYPE specifies the encoding of the
   data stream.  All servers must support "1404" encoding.  Others forms
   may be supported as desired.

   If the server, while retrieving the data, cannot retrieve some
   portion of the data (i.e., some of the data previously found
   disappeared between the time of the SELECT and the time of the GET),
   then the server must return a 150 error.  If the client requests an
   encoding type not supported by the server, then the server must
   return a 151 error.

   The format of the returned data is as follows:

    RETURN-DATA-TYPE   ::=   START-DATA  <RETURN-TYPE>  <DATA>   END-DATA
    RETURN-TYPE       ::=  1404 | <ASCII-STRING>

    An example would be:

    >GET ABC 1404
    <951 "OK, here it comes!"
    <START-DATA 1404

    1404 data stream here...

    <END-DATA
    <952 "All done!"

    Error examples:

    >GET ABC STRONG-CRYPT
    <151 "Sorry, that encoding not available here"

    or

    >GET ABC 1404
    <951 "OK, here it comes!"



Clark                        Informational                     [Page 10]

RFC 1856               Opstat Client-Server Model           October 1995


    <START-DATA 1404

    1404 data stream here...

    <END-DATA
    <150 "Whoa, bad data..."

   If any type of error code is returned by the server, the client must
   discard all data received from the server.

3.7  The LIST Command

   The LIST command allows the client to query the server about
   available data residing on the server.  The LIST command has the
   format:

    LIST-CMD  ::=  LIST <net> <dev> <intf> <var> <gran> <sdate> <stime>
                   <edate> <etime>
    <net>     ::=  <ASCII-STRING> | *
    <dev>     ::=  <ASCII-STRING> | *
    <intf>    ::=  <ASCII-STRING> | *
    <var>     ::=  <ASCII-STRING> | *
    <gran>    ::=  <ASCII-STRING> | *
    <sdate>   ::=  <DATE-TYPE>    | *
    <edate>   ::=  <DATE-TYPE>    | *
    <stime>   ::=  <TIME-TYPE>    | *
    <etime>   ::=  <TIME-TYPE>    | *

   For example, to get a list of networks that the server has data for,
   you would use the command:

    LIST * * * * * * * * *

    The command

    LIST netx rtry * * * * * * *

    will list all interfaces for rtry.  The command

    LIST netx rtry * ifInOctets * 1993-02-01 * * *

   will get the list of interfaces on device "rtry" in network "netx"
   which have values for the variable "ifInOctets" after the start date
   of Februrary 1, 1993.







Clark                        Informational                     [Page 11]

RFC 1856               Opstat Client-Server Model           October 1995


   To process wildcards in a LIST command, follow these rules:

    1)  Only the leftmost wildcard will be serviced for a given
        LIST command
    2)  If all fields to the right of the leftmost wildcard are
        wildcards, then all values for the wildcard being processed
        will be returned.
    3)  If specific values are given for fields to the right of the
        wildcard being serviced, then the specific values must match
        a known value

   The output from the LIST command is formatted as follows:

    LIST-RETURN  ::=  START-LIST <LIST-ENTRY> END-LIST
    LIST-ENTRY   ::=  <net> <device> <intf> <var> <gran> <sdate> <stime>
                      <edate> <etime>
    <net>        ::=  <ASCII-STRING>
    <device>     ::=  <ASCII-STRING> | <NULL>
    <intf>       ::=  <ASCII-STRING> | <NULL>
    <var>        ::=  <ASCII-STRING> | <NULL>
    <gran>       ::=  <ASCII-STRING> | <NULL>
    <sdate>      ::=  <DATE-TYPE>    | <NULL>
    <edate>      ::=  <DATE-TYPE>    | <NULL>
    <stime>      ::=  <TIME-TYPE>    | <NULL>
    <etime>      ::=  <TIME-TYPE>    | <NULL>

   Note that only the fields with values in them will be returned by the
   server.  For example, the query to find the interfaces on rtry:

    >LIST netx rtry * * * * * * *
    <941 "OK, here comes the list..."
    <START-LIST
    <netx rtry intf1
    <netx rtry intf2
    <netx rtry intf3
    <END-LIST
    <942 "all done"

   The query to find interfaces having ifInOctets data with a 15 minute
   granularity:

    >LIST netx rtry * ifInOctets 15min * * * *
    <941 "OK, here comes the list..."
    <START-LIST
    <netx rtry intf1
    <netx rtry intf2
    <netx rtry intf3
    <END-LIST



Clark                        Informational                     [Page 12]

RFC 1856               Opstat Client-Server Model           October 1995


    <942 "all done"

   If, while processing a LIST command, the server encounters an error,
   then the server must return a 140 error message.  If the server
   cannot process the LIST command (syntax error, etc.), then it must
   return a 141 message.  For example:

    >LIST netx rtry
    <141 "huh, bad list dude"

    or

    >LIST netx rtry * ifInOctets 15min * * * *
    <941 "OK, here comes the list..."
    <START-LIST
    <netx rtry intf1
    <netx rtry intf2
    <netx rtry intf3
    <END-LIST
    <140 "Whoa, bad list dude, please ignore"

3.8  The Server State Machine

   The state machine pictured below describes how a server should
   interact with a client:


                         +------+
               +-------->| WAIT |<-----+
               |         +------+      |
               |  New       |          |
               |  Connect   |          |  LOGIN Failure
     EXIT      |           \ /         |
     Received  |         +-------+     |
               |         | LOGIN |-----+
               |         +-------+
               |             |
               |             |  LOGIN Successful
               |            \ /
               |        +---------+
               +--------| PROCESS |<----+
                        +---------+     |
                             |          |  Process Commands
                             |          |
                             +----------+






Clark                        Informational                     [Page 13]

RFC 1856               Opstat Client-Server Model           October 1995


   The server normally stays in WAIT (after starting and initialization)
   until a new connection is made from a client.  The first command a
   client must issue is a LOGIN command, otherwise the server must
   immediately close the connection.  If the login process fails in any
   way (as described in 3.2), then the server must immediately close the
   connection and return to the WAIT state.

   Once a successful LOGIN is received, the server enters the PROCESS
   state where it processes some number of LIST, GET, STATUS, and SELECT
   commands. Any other command received while in this state must be
   ignored, except for the EXIT command.  Once an EXIT command is
   received, the server exits immediately (after perfoming any needed
   internal bookkeeping) and returns to the WAIT state.  Any command a
   server receives while processing a command (e.g., if you send an
   "EXIT" while a large "GET" is being processed) will be ignored until
   the command being processed completes.

   If the data connection to the client closes for any reason while the
   server is in the PROCESS state, the server must immediately close its
   connection and do any associated internal cleanup and return to the
   LOGIN state.

4.0  Security Issues

   There are legal, ethical and political concerns of data sharing.  For
   this reason there is a need to insure integrity and confidentiality
   of any shared data.  Although not specified in this standard,
   mechanisms to control a user's access to specific data about specific
   objects may need to be included in server implementations.  This
   could potentially be done in several ways, including a configuration
   file that listed the objects a user was allowed to access or limiting
   file access by using file permissions within a given file system.  At
   a minimum, the server should not allow default access to all data on
   the server.

   Additionally, the server should strictly follow the state diagram
   shown in section 3.8.  The server should be tested with arbitrary
   strings in the command fields to ensure that no unexpected security
   problems will be caused by the server.  The server should
   specifically discard illegal ASCII characters as discussed in section
   3.0.  If the server executes other programs, then the server must
   verify that no unexpected side-effects will occur as the result of
   the invocation or the arguments given to that program.  The server
   should always verify that all data is contained within the input
   buffer, and that a long input string from a client will not cause
   unexpected side-effects.





Clark                        Informational                     [Page 14]

RFC 1856               Opstat Client-Server Model           October 1995


   Finally, given the relative insecurity of the global Internet, and
   the presence of packet-sniffing capability, several considerations
   must be weighed.  The authentication process via the LOGIN process
   must be strictly adhered to, and the use of one-time authentication
   is strongly encouraged.  It is also suggested that the data returned
   from the server be protected (such as through encryption) so that no
   sensitive data is revealed by accident.

5.0  Summary

   This document defines a protocol which could be used in a client-
   server relationship to retrieve statistics from a remote database
   server.

   Much work remains to be done in the area of Operational Statistics
   including questions such as:

    - what "standard" graphs or "variables" should always be made
      available to the user?
    - what additions to the standard MIB would make the network
      manager's job easier?

6.0  References

   [1] Stockman, B., "A Model for Common Operational Statistics", RFC
       1404, NORDUnet/SUNET, January 1993.

























Clark                        Informational                     [Page 15]

RFC 1856               Opstat Client-Server Model           October 1995


Appendix A:  Sample Client-Server Sessions

   Session 1: Check available variables on device rtr1 interface eth0

    >LOGIN "henry" "skey"
    <CHAL "78 lo35098"
    >AUTH "COW MOO DOG BARK CAT MEOW"
    <910 "Login OK, what now?"
    >LIST OARnet rtr1 eth0 * * * *
    <941 "List lookup OK, here it comes!"
    <START-LIST
    <OARnet rtr1 eth0 ifInOctets
    <OARnet rtr1 eth0 ifOutOctets
    <OARnet rtr1 eth0 ifInErrors
    <OARnet rtr1 eth0 ifOutErrors
    <END-LIST
    <942 "List done!"
    >EXIT
    <990 "OK, Bye now!"


    Session 2: Retrieve a bit of data from the server


    >LOGIN henryc "skey"
    <CHAL "78 lo35098"
    >AUTH "COW MOO DOG BARK CAT MEOW"
    <910 "Login OK, what now?"
    >SELECT OARnet rtr1 eth0 InBytes 15min 1993-02-01 00:00:00 1993-03-01 23:59:59
    <920 "TAG blah"
    >STATUS
    <931 "here it comes..."
    <STATUS= OK
    <TAG blah SIZE 654321
    <932 "all done"
    >GET blah 1404
    <951 "here it comes..."
    <START-DATA 1404

      1404 data here

    <END-DATA
    <952 "wow, all done"
    >EXIT
    <990 "OK, bye"






Clark                        Informational                     [Page 16]

RFC 1856               Opstat Client-Server Model           October 1995


Author's Address

Henry Clark
BBN Planet Corp.
150 Cambridge Park Dr.
Cambridge, MA 02140

Phone:  [phone]
EMail:  [e-mail]










































Clark                        Informational                     [Page 17]