Editing XML Management Protocol (section)

=== Message Types ===

XMP is connection-oriented and thus does not suffer many of the intricacies of the SNMP.  The original arguments for the architecture of the SNMP were valid and appropriate for the time frame it was developed.  However, today's computer systems (and even embedded networking equipement) have far more powerful processors, have more memory, and are cheaper than those devices of yesterday.  Rather than continue to contort oneself to the economics of the 1980s, we decided to take advantage of the explosion in performance-to-price ratio of today's computer and networking hardware.

In order to make XML parsing more deterministic, each XMP message is prepended with a 32-byte ''wire header'' which consists of a 4 ASCII-character XMP version field, a 12 ASCII-character field containing a base-10 length, and 16 ASCII-character ''authenUser'' field.  The length field tells the receiver how long the following XMP PDU is in octets while the version field future-proofs the protocol, and the ''authenUser'' field provides for protocol-engine processing of coarse-grained MIB views and access-control.

(Compare the above approach with that used when parsing ASN.1/BER to show why this is more efficient.)

Message types borrowed from the SNMP include:

* '''Response''' sent in response to both scalar and tabular queries.
 
* '''GetRequest''' sent by a manager to obtain the values of scalar variables.

* '''SetRequest''' sent by a manager to modify the values of scalar variables.

* '''Trap''' sent by an agent to notify a manager of the occurrence of some event.

* '''Information''' sent by an agent to a peer or manager to convey un-solicited information.

We have introduced new message types for table operations:

* '''SelectTableRequest''' sent by a manager to perform a Select operation on a MIB table.  Using this operation with key ''*'' is roughly equivalent to walking a MIB table in the Internet Management Framework.  Using ''SelectTableRequest'', however, will result in a consistent view of the table because the agent will lock the table during message processing.  With SNMP MIB table walks, the manager is not guaranteed to get a single, consistent view of the MIB table.  That is, by the time the SNMP manager is done walking a table, rows obtained during the walk are not guaranteed to have ever simultaneously  coexisted in the table.

* '''InsertTableRequest''' sent by a manager to perform an Insert operation on a MIB table.  Using this operation avoids the whole RowStatus textual-convention fiasco associated with creating MIB table entries using SNMP.

* '''DeleteTableRequest''' sent by a manager to perform a Delete operation on a MIB table.  Again, using this operation avoids deleting rows as a side-effect of an SNMP Set operation using the RowStatus textual convention.

* '''UpdateTableRequest''' sent by a manager to perform an Update operation on a MIB table.

As one can see, the most notable changes from SNMP include the addition of SQL-like table operations.  SNMP table operations are cumbersome, confusing, difficult to implement, and error-prone.  Since tables are modeled as relations in the SNMP, why not apply relational database table operations?  Still another major difference from the SNMP is the complete lack of ''GetNext'' operation.  In XMP, a ''GetNext'' operation is simply not needed -- performing SNMP ''GetNext''  operations yields very little additional information and no additional semantics.

How does one walk a MIB then like one does with SNMP?  The XMP does not support this.  In practice, walking a MIB gave only syntactic information, not semantic.  Without semantic information, the results of a MIB walk are of dubious value anyway.  Intelligent management applications have to know the semantics of the management information they are dealing with thus they must know the semantics a prior.  Finally, MIB walks were useful for discovering the contents of SNMP tables.  However, those SNMP MIB walks can introduce race conditions since a table may change while its being walked.  In XMP table implementations, the table is locked while ''SelectTableRequest'', ''InsertTableRequest'', ''DeleteTableRequest'', and ''UpdateTableRequest'' operations are being performed thus the they return a consistent view of tables.