rfc1076.txt

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

Network Working Group                                         G. Trewitt
Request for Comments: 1076                           Stanford University
Obsoletes: RFC 1023                                         C. Partridge
                                                                BBN/NNSC
                                                           November 1988


                  HEMS Monitoring and Control Language

                           TABLE OF CONTENTS

1.   Status of This Memo                                               1
     Introduction                                                      2
2.   Overview and Scope                                                2
3.   Overview of Query Processor Operation                             4
4.   Encoding of Queries and Responses                                 5
4.1  Notation Used in This Proposal                                    5
5.   Data Organization                                                 6
5.1  Example Data Tree                                                 7
5.2  Arrays                                                            8
6.   Components of a Query                                             9
7.   Reply to a Query                                                 10
8.   Query Language                                                   12
8.1  Moving Around in the Data Tree                                   14
8.2  Retrieving Data                                                  15
8.3  Data Attributes                                                  16
8.4  Examining Memory                                                 18
8.5  Control Operations:  Modifying the Data Tree                     19
8.6  Associative Data Access:  Filters                                21
8.7  Terminating a Query                                              26
9.   Extending the Set of Values                                      27
10.  Authorization                                                    27
11.  Errors                                                           28
I.   ASN.1 Descriptions of Query Language Components                  29
I.1  Operation Codes                                                  30
I.2  Error Returns                                                    31
I.3  Filters                                                          33
I.4  Attributes                                                       34
I.5  VendorSpecific                                                   36
II.  Implementation Hints                                             36
III. Obtaining a Copy of the ASN.1 Specification                      42

1. STATUS OF THIS MEMO

   This RFC specifies a query language for monitoring and control of
   network entities.  This RFC supercedes RFC-1023, extending the query
   language and providing more discussion of the underlying issues.




Trewitt & Partridge                                             [Page 1]

RFC 1076          HEMS Monitoring and Control Language     November 1988


   This language is a component of the High-Level Entity Monitoring
   System (HEMS) described in RFC-1021 and RFC-1022.  Readers may wish
   to consult these RFCs when reading this memo.  RFC-1024 contains
   detailed assignments of numbers and structures used in this system.
   Portions of RFC-1024 that define query language structures are
   superceded by definitions in this memo.  This memo assumes a
   knowledge of the ISO data encoding standard, ASN.1.

   Distribution of this memo is unlimited.

INTRODUCTION

   This RFC specifies the design of a general-purpose, yet efficient,
   monitoring and control language for managing network entities.  The
   data in the entity is modeled as a hierarchy and specific items are
   named by giving the path from the root of the tree.  Most items are
   read-only, but some can be "set" in order to perform control
   operations.  Both requests and responses are represented using the
   ISO ASN.1 data encoding rules.

2. OVERVIEW AND SCOPE

   The basic model of monitoring and control used in this memo is that a
   query is sent to a monitored entity and the entity sends back a
   response.  The term query is used in the database sense -- it may
   request information, modify data, or both.  We will use gateway-
   oriented examples, but it should be understood that this query-
   response mechanism is applicable to any IP entity.

   In particular, there is no notion of an interactive "conversation" as
   in SMTP [RFC-821] or FTP [RFC-959].  A query is a complete request
   that stands on its own and elicits a complete response.

   In order to design the query language, we had to define a model for
   the data to be retrieved by the queries, which required some
   understanding of and assumptions to be made about the data.  We ended
   up with a fairly flexible data model, which places few limits on the
   type or size of the data.

   Wherever possible, we give motivations for the design decisions or
   assumptions that led to particular features or definitions.  Some of
   the important global considerations and assumptions are:

         - The query processor should place as little computational
           burden on the monitored entity as possible.

         - It should not be necessary for a monitored entity to store
           the complete query.  Nothing in the query language should



Trewitt & Partridge                                             [Page 2]

RFC 1076          HEMS Monitoring and Control Language     November 1988


           preclude an implementation from being able to process the
           query on the fly, producing portions of the response while
           the query is still being read and parsed.  There may be
           other constraints that require large amounts of data to be
           buffered, but the query language design must not be one.

         - It is assumed that there is some mechanism to transport a
           sequence of octets to a query processor within the
           monitored entity and that there is some mechanism to return
           a sequence of octets to the entity making the query.  In
           HEMS, this is provided by HEMP and its underlying transport
           layer.  The query language design is independent of these
           details, however, and could be grafted onto some other
           protocol.

         - The data model must provide organization for the data, so
           that it can be conveniently named.

         - Much of the data to be monitored will be contained in
           tables.  Some tables may contain other tables.  The query
           language should be able to deal with such tables.

         - We don't provide capabilities for data reduction in the
           query language.  We will provide for data selection, for
           example, only retrieving certain table entries, but we will
           not provide general facilities for processing data, such as
           computing averages.

         - Because one monitoring center may be querying many
           (possibly hetrogenous) hosts, it must be possible to write
           generic queries that can be sent to all hosts, and have the
           query elicit as much information as is available from each
           host.  i.e., queries must not be aborted just because they
           requested non-existent data.

   There were some assumptions that we specifically did not make:

         - It is up to the implementation to choose what degree of
           concurrency will be allowed when processing queries.  By
           locking only portions of the database, it should be
           possible to achieve good concurrency while still preventing
           deadlock.

         - This specification makes no statement about the use of the
           "definite" and "indefinite" length forms in ASN.1.  There
           is currently some debate about this usage in the ISO
           community; implementors should note the recommendations in
           the ASN.1 specification.



Trewitt & Partridge                                             [Page 3]

RFC 1076          HEMS Monitoring and Control Language     November 1988


   Other RFCs associated with HEMS are:

      RFC-1021        Overview;
      RFC-1022        Transport protocol and message encapsulation;
      RFC-1024        Precise data definitions.

   The rest of this report is organized as follows:

      Section 3       Gives a brief overview of the data model and the
                      operation of the query processor.

      Section 4       Describes the encoding used for queries and
                      responses, and the notation used to represent them
                      in this report.

      Section 5       Describes how the data is organized in the
                      monitored entity, and the view provided of it by
                      the query processor.

      Section 6       Describes the basic data types that may be given
                      to the query processor as input.

      Section 7       Describes how a reply to a query is organized.

      Section 8       Describes the operations available in the query
                      language.

      Section 9       Describes how the set of data in the tree may be
                      extended.

      Section 10      Describes how authorization issues affect the
                      execution of a query.

      Section 11      Describes how errors are reported, and their
                      effect on the processing of the query.

      Appendix I      Gives precise ASN.1 definitions of the data types
                      used by the query processor.

      Appendix II     Gives extensive implementation hints for the core
                      of the query processor.

3. OVERVIEW OF QUERY PROCESSOR OPERATION

   In this section, we give an overview of the operation of the query
   processor, to provide a framework for the later sections.

   The query language models the manageable data as a tree, with each



Trewitt & Partridge                                             [Page 4]

RFC 1076          HEMS Monitoring and Control Language     November 1988


   branch representing a different aspect of the entity, such as
   different layers of protocols.  Subtrees are further divided to
   provide additional structure to the data.  The leaves of the tree
   contain the actual data.

   Given this data representation, the task of the query processor is to
   traverse this tree and retrieve (or modify) data specified in a
   query.  A query consists of instructions to move around in the tree
   and to retrieve (or modify) named data.  The result of a query is an
   exact image of the parts of the tree that the query processor
   visited.

   The query processor is very simple -- it only understands eight
   commands, most of which share the same structure.  It is helpful to
   think of the query processor as an automaton that walks around in the
   tree, directed by commands in the query.  As it moves around, it
   copies the tree structure it traverses to the query result.  Data
   that is requested by the query is copied into the result as well.
   Data that is changed by a query is copied into the result after the
   modification is made.

4. ENCODING OF QUERIES AND RESPONSES

   Both queries and responses are encoded using the representation
   defined in ISO Standard ASN.1 (Abstract Syntax Notation 1).  ASN.1
   represents data as sequences of <tag,length,contents> triples that
   are encoded as a stream of octets.  The data tuples may be
   recursively nested to represent structured data such as arrays or
   records.  For a full description, see the ISO standards IS 8824 and
   IS 8825.  See appendix for information about obtaining these
   documents.

4.1 Notation Used in This Proposal

   The notation used in this memo is similar to that used in ASN.1, but
   less formal, smaller, and (hopefully) easier to read.  We will refer
   to a <tag,length,contents> tuple as a "data object".  In this RFC, we
   will not be concerned with the details of the object lengths.  They
   exist in the actual ASN.1 encoding, but will be omitted in the
   examples here.

   Data objects that have no internal ASN.1 structure such as integer or
   octet string are referred to as "simple types" or "simple objects".
   Objects which are constructed out of other ASN.1 data objects will be
   referred to as "composite types" or "composite objects".






Trewitt & Partridge                                             [Page 5]

RFC 1076          HEMS Monitoring and Control Language     November 1988


   The notation
       ID(value)
   represents a simple object whose tag is "ID" with the given value.  A
   composite object is represented as
       ID{ ... contents ... }
   where contents is a sequence of data objects.  The contents may
   include both simple and structured types, so the structure is fully
   recursive.

   The difference between simple and composite types is close to the
   meaning of the "constructor" bit in ASN.1.  For the uses here, the
   distinction is made based upon the semantics of the data, not the
   representation.  Therefore, even though an OctetString can be
   represented in ASN.1 using either constructed or non-constructed
   forms, it is conceptually a simple type, with no internal structure,