rfc1028.txt

<VC++网络游戏建摸与实现>源代码

   only at the request of the application user.

3.2.  The Get Response Message Type

   The form of messages of this type is identical to that of Get Request
   type messages except for the indication of message type. In the CCITT
   X.409 language,

   get_rsp_message_type    ::=     [ APPLICATION 2 ] IMPLICIT

                           SEQUENCE {




Davin, Case, Fedor and Schoffstall                              [Page 6]

RFC 1028               Simple Gateway Monitoring           November 1987


                           request_id              request_id_type,
                           error_status            error_status_type,
                           error_index             error_index_type,
                           var_op_list             var_op_list_type

                           }

   The response of a protocol entity to a message of this type is to
   present its contents to the application user.

   Messages of the Get Response type are generated by a protocol entity
   only upon receipt of Set Request or Get Request type messages as
   described elsewhere in this document.

3.3.  The Trap Request Message Type

   The form of a message of this type is described below in the language
   defined in the CCITT X.409 recommendation:

   val_list_type           ::=     SEQUENCE OF var_value_type

   trap_type_type          ::=     INTEGER

   trap_req_message_type   ::=     [ APPLICATION 3 ] IMPLICIT

                           SEQUENCE {

                           trap_type               trap_type_type,
                           val_list                val_list_type

                           }

   The response of a protocol entity to a message of this type is to
   present its contents to the application user.

   Messages of the Trap Request type are generated by a protocol entity
   only at the request of the application user.

   The significance of the val_list component of a Trap Request type
   message is implementation-specific.

   Interpretations for negative values of the trap_type field are
   implementation-specific.  Interpretations for non-negative values of
   the trap_type field are defined below.

3.3.1.  The Cold Start Trap Type

   A Trap Request type message for which the value of the trap_type



Davin, Case, Fedor and Schoffstall                              [Page 7]

RFC 1028               Simple Gateway Monitoring           November 1987


   field is 0, signifies that the sending protocol entity is
   reinitializing itself such that the gateway configuration or the
   protocol entity implementation may be altered.

3.3.2.  The Warm Start Trap Type

   A Trap Request type message for which the value of the trap_type
   field is 1, signifies that the sending protocol entity is
   reinitializing itself such that neither the gateway configuration nor
   the protocol entity implementation is altered.

3.3.3.  The Link Failure Trap Type

   A Trap Request type message for which the value of the trap_type
   field is 2, signifies that the sending protocol entity recognizes a
   failure in one of the communication links represented in the gateway
   configuration.

3.3.4.  The Authentication Failure Trap Type

   A Trap Request type message for which the value of the trap_type
   field is 3, signifies that the sending protocol entity is the
   addressee of a protocol message that is not properly authenticated.

3.3.5.  The EGP Neighbor Loss Trap Type

   A Trap Request type message for which the value of the trap_type
   field is 4, signifies that an EGP neighbor for whom the sending
   protocol entity was an EGP peer has been marked down and the peer
   relationship no longer obtains.

3.4.  The Set Request Message Type

   The form of messages of this type is identical to that of Get Request
   type messages except for the indication of message type.  In the
   CCITT X.409 language:

   set_req_message_type    ::=     [ APPLICATION 4 ] IMPLICIT

                           SEQUENCE {

                           request_id              request_id_type,
                           error_status            error_status_type,
                           error_index             error_index_type,
                           var_op_list             var_op_list_type

                           }




Davin, Case, Fedor and Schoffstall                              [Page 8]

RFC 1028               Simple Gateway Monitoring           November 1987


   Upon receipt of a message of this type, the receiving entity responds
   according to any applicable rule in the list below:

   (1)  If, for some var_op_type component of the received message, the
        value of the var_name field names no variable known to the
        receiving entity, then the receiving entity sends to the
        originator of the received message a message of identical form
        except that the indicated message type is Get Response, the
        value of the error_status field is gmp_err_nix_name, and the
        value of the error_index field is the unit-based index of said
        var_op_type component in the received message.

   (2)  If, for some var_op_type component of the received message, the
        contents of the var_value field does not, according to the CCITT
        X.409 recommendation, manifest a type, length, and value that is
        consistent with that required for the variable named by the
        value of the var_name field, then the receiving entity sends to
        the originator of the received message a message of identical
        form except that the indicated message type is Get Response, the
        value of the error_status field is gmp_err_bad_value, and the
        value of the error_index field is the unit-based index of said
        var_op_type component in the received message.

   (3)  If the size of the Get Response type message generated as
        described below would exceed the size of the largest message for
        which the protocol definition requires acceptance, then the
        receiving entity sends to the originator of the received
        message a message of identical form except that the indicated
        message type is Get Response, the value of the error_status
        field is gmp_err_too_big, and the value of the error_index field
        is zero.

   If none of the foregoing rules apply, then for each var_op_type
   component of the received message, according to the sequence of such
   components represented by said message, the value represented by the
   var_value field of the given component is assigned to the variable
   named by the value of the var_name field of that component.  The
   receiving entity sends to the originator of the received message a
   message of identical form except that the indicated message type is
   Get Response, the value of the error_status field is gmp_err_noerror,
   and the value of the error_index field is zero.

   Messages of the Set Request type are generated by a protocol entity
   only at the request of the application user.

   Recognition and processing of Set Request type frames is not required
   by the protocol definition.




Davin, Case, Fedor and Schoffstall                              [Page 9]

RFC 1028               Simple Gateway Monitoring           November 1987


4.  The Authentication Protocol

   The authentication protocol is a session-layer protocol by which
   messages specified by a protocol user are selectively delivered to
   other protocol users.  The protocol definition precludes delivery to
   a protocol user of any user message for which the protocol
   representation lacks a specified "authentic" form.

   Communication among authentication protocol entities is accomplished
   by the exchange of protocol messages, each of which is entirely and
   independently represented by a single UDP datagram.  An
   authentication protocol entity responds to protocol messages received
   at UDP port 153 on the host with which it is associated.

   A half-session of the authentication protocol is, for any ordered
   pair of protocol users, the set of messages sent from the first user
   of the pair to the second user of said pair.  A session of the
   authentication protocol is defined to be union of two complementary
   half-sessions of the protocol - that is, the set of messages
   exchanged between a given pair of protocol users.  Associated with
   each protocol half-session is a triplet of functions:

   (1)  The authentication function for a given half-session is a
        boolean-valued function that characterizes the set of
        authentication protocol messages that are of acceptable,
        authentic form with respect to the set of all possible
        authentication protocol messages.

   (2)  The message interpretation function for a given half-
        session is a mapping from the set of authentication
        protocol messages accepted by the authentication function
        for said half-session to the set of all possible user
        messages.

   (3)  The message representation function for a given half-
        session is a mapping that is the inverse of the message
        interpretation function for said half-session.

   The association between half-sessions of the authentication protocol
   and triplets of functions is not defined in this document.

   The form and function of the single message type recognized by a
   protocol entity is described below.  The type of a given protocol
   message is indicated by the value of the implicit type tag for the
   data structure that is represented by said message according to the
   conventions of the CCITT X.409 recommendation.





Davin, Case, Fedor and Schoffstall                             [Page 10]

RFC 1028               Simple Gateway Monitoring           November 1987


4.1.  The Data Request Message Type

   Messages of this type are represented by a sequence of fields whose
   form and interpretation are described below.

4.1.1.  The Message Length Field

   The Message Length field of a given Data Request message represents
   the length of said message as an unsigned, 16-bit, binary integer.
   This value is encoded such that more significant bits precede less
   significant bits in the order of transmission and includes the length
   of the Message Length field itself.

4.1.2.  The Session ID Length Field

   The Session ID Length field of a given Data Request message
   represents the length, in octets, of the Session ID field of said
   message.  This value is encoded as an unsigned, 8-bit, binary
   integer.

4.1.3.  The Session ID Field

   The Session ID field of a given Data Request message represents the
   name of the protocol session to which said message belongs.  The
   value of this field is encoded as asequence of octets whose length is
   the value of the Session ID Length field for said message.

4.1.4.  The User Data Field

   The User Data field of a given Data Request message represents a
   message being passed from one protocol user to another.  The value of
   this field is encoded according to conventions implicit in the
   message representation function for the appropriate half of the
   protocol session named by the value of the Session ID field for said
   message.

   Upon receipt of a Data Request type message, the receiving
   authentication protocol entity verifies the form of said message by
   application of the authentication function associated with its half
   of the session named by the value of the Session ID field in the
   received message.  If the form of the received message is accepted as
   "authentic" by said function, then the user message computed by the
   application of the message interpretation function for said half-
   session to the value of the User Data field of the received message
   is presented to the protocol user together with an indication of the
   protocol session to which the received message belongs.





Davin, Case, Fedor and Schoffstall                             [Page 11]

RFC 1028               Simple Gateway Monitoring           November 1987


   Otherwise, the message is discarded and an indication of the receipt
   of an unauthenticated message is presented to the protocol user.

   A message of this type is generated only at the request of the
   protocol user to communicate a message to another user of the
   protocol.  Such a request specifies the user message to be sent as
   well as the session of the authentication protocol to which said user
   message belongs.  The value of the Session ID field of the generated
   message is the name of the session specified in the user request.
   The value of the User Data field of the generated message is computed
   by applying the message representation function for the appropriate
   half of the specified session to the specified user message.

5.  Variable Names

   The variables retrieved or manipulated by the application protocol
   are named by octet string values.  Such values are represented in
   this document in two ways:

   (1)  A variable name octet string may be represented
       numerically by a sequence of hexadecimal numbers, each of
       which denotes the value of the corresponding octet in