Open Agent Architecture (OAA) Multiple Component SNMP Agent (MCSA) SNMP/MCSA/Agent (Draft) by Bill White, et al Version 0.8 10/30/94 1.0 Multiple Component SNMP Agent (MCSA) Design Objective The central design objective of the MCSA agent is to allow multiple SNMP agent components from different vendors to interoperate, collectively realizing a system's SNMP agent. The MCSA design defines communication among SNMP agent components in system independent, message based component dialogue protocols that embody all intercomponent agent operations so they can be defined by mandatory RFCs. The design seeks to limit system dependent definitions to the specification of the method of intercomponent message exchange, mapping a primitive, generic MCSA API abstraction to each system platform's specific API by recommended RFCs. 1.1 Multiple Component SNMP Agent (MCSA) Reference Model A system has one SNMP Agent. This agent is divided into components: an SNMP/MCSA/Agent/Master ("Agent/Master") and none or more SNMP/MCSA/Agent/SubAgentComponents ("Agent/SubAgentComponent"). Given an identical MIB state and SNMP packet, all MCSA agents should respond identically and correctly, whatever each MCSA Agent's underlying component configuration, and be externally indistinguishable from a monolithic agent. All intercomponent operations, either between Agent/Master and Agent/SubAgentComponent or among Agent/SubAgentComponents, are by exchange of MCSA Component Messages whose processing is defined by system independent, MCSA Component Dialogue Protocols. Intra-agent communication among an MCSA/Agent's Master and SubAgentComponents is a form of inter-process communication using messages whose medium of exchange is a function of the agent's host's system and communication configuration. |===============================================| | MCSA Generic API Abstraction | | for MCSA Message Exchange | (mandatory) |===============================================| ^ | ^ | | | | | | | (MCSA Component Dialogue | | | | Protocols) | | | | | | | | (mandatory) | | | v | v ============== ============== | system-API | | system-API | (recommended) |=======================| |=======================| | SNMP/Agent/Master | | SNMP/Agent/Component-n|(vendor specific) |=======================| |=======================| Figure 1 - Multiple Component SNMP Agent Communications 1.2 MCSA Agent/Master The Agent/Master is a system's end point for all incoming SNMP packets; the overseer all SNMP packet processing; the sender of all SNMP responses and traps. And, as such, is responsible for the agent's compliance with all SNMP protocols. An MCSA agent has one Agent/Master. The Agent/Master services a known, Agent/Master message queue, providing MCSA agent wide services to other Agent/SubAgentComponents (i.e. queue management, message forwarding, system up time, resource enqueue, component registration, event subscription, etc) as defined in the Agent/Master's MCSA Component Dialogue Protocol For or participating in other Component Message exchanges with Agent/SubAgentComponents defined by the Agent/SubAgentComponent's MCSA Component Dialogue Protocol. Whenever appropriate, the Agent/Master bears the burden of processing and context retention rather than the Agent/SubAgentComponents. 1.3 MCSA Agent/SubAgentComponents Agent/SubAgentComponents provide or obtain services through the exchange of Component Messages with the Agent/Master or other Agent/SubAgentComponents as defined in the relevant MCSA Component Dialogue Protocols (i.e. Agent/SubAgentComponents that send and receive packets over a particular transport; Agent/SubAgentComponents that support ranges of OIDs). An MCSA agent may have any number of Agent/SubAgentComponents. 1.4 MCSA Message Exchange Each system platform type defines a system dependent mapping of the MCSA Generic Message Exchange API abstraction to its in a recommended RFC - "MCSA Message Exchange API For ", including the system dependent definition of a component, a message queue and the method of message exchange realization. The MCSA Agent's Agent/Master and Agent/SubAgentComponents declare MCSA Message Queues and exchange MCSA Component Messages via their system's implementation of the MCSA Message Exchange. If a system has multiple processors, the MCSA Message Exchange must be implemented on all processors having MCSA message queues. 1.5 MCSA Hierarchy Agent/SubAgentComponents and the Agent/Master are the realization of the MCSA Component Dialogue Protocols they support. The MCSA Component Dialogue Protocols are made up of their Component Message definitions. Component Messages are made up of Component Message Fields and methods of implementation. Component Message Fields are made up of Field Elements and methods of implementation. MCSA Agent | | |--> Agent/Master (message queue) | |--> Agent/SubAgentComponent-1 (message queue) | |--> Agent/SubAgentComponent-n (message queue) | | |--> Component Dialogue Protocol-1 | |--> Component Dialogue Protocol-n | | |--> Component Message-1 | |--> Component Message-n | | |--> Message Field-1 | |--> Message Field-n | | |--> Field Element-1 | |--> Field Element-2 | |--> Field Element-3 2.0 MCSA Component Dialogue Protocols Defined: 2.1 MCSA Component Dialogue Protocol For System Time: This Component Dialogue Protocol defines the message exchange between the Agent/Master and Agent/SubAgentComponents for obtaining the System Up Time from the Agent/Master; obtaining system time; time delayed message forwarding; time tick message requests. 2.2 MCSA Component Dialogue Protocol For OID Servers: This Component Dialogue Protocol defines the message exchange between the Agent/Master and Agent/SubAgentComponents acting as OID servers that support resolution of one or more OID instances. The Agent/Master registers all Agent/SubAgentComponents OIDs servers, including arbitration for support conflicts and multiple component table support such as dynamic assignment of table indices. The Agent/Master exchanges Component Messages with Agent/SubAgentComponent/OIDServers to process an SNMP packet. 2.3 MCSA Component Dialogue Protocol For Message Queue Services This Component Dialogue Protocol defines the message exchange between the Agent/Master and the Agent/SubAgentComponent/MsgQServer for registering and locating message queues; sending messages to a message queue; registering message types. 2.4 MCSA Component Dialogue Protocol For Master Message Servers This Component Dialogue Protocol defines the message exchange between the Agent/Master and Agent/Master/MsgServer that supports the registration of components that process Agent/Master Component Messages on behalf of the Agent/Master, extending the Agent/Master. 2.5 MCSA Component Dialogue Protocol For OID Query [and Set?] This Component Dialogue Protocol defines the message exchange to allow any Agent/SubAgentComponent to query either another intrasystem OID Server or a remote SNMP agent for OID values with either a get or getnext request. 2.6 MCSA Component Dialogue Protocol For Traps This Component Dialogue Protocol defines the message exchange to allow any Agent/SubAgentComponent to send an SNMP trap through the Agent/Master. 2.7 MCSA Component Dialogue Protocol For Packet Header This Component Dialogue Protocol defines the message exchange between the Agent/Master and a Agent/SubAgentComponent/MsgQServer for obtaining SNMP packet header information. 2.8 MCSA Component Dialogue Protocol For Transport Servers: This Component Dialogue Protocol defines the message exchange between the Agent/Master and Agent/SubAgentComponent/Transport that send and receive SNMP packets on behalf of the Agent/Master. [TBD] 2.9 MCSA Component Dialogue Protocol For Resource Naming and Control This Component Dialogue Protocol defines the message exchange between the Agent/Master and Agent/SubAgentComponents/Resource that supports the naming of and access control to shared resources. [TBD] 2.10 MCSA Component Dialogue Protocol For Event Subscription This Component Dialogue Protocol defines the message exchange between the Agent/Master and Agent/SubAgentComponents/Event that supports the registration event publishers and subscribers. [TBD] 3.0 SNMP/MCSA/Agent API The MCSA API is a handful of function calls needed to use and manage the MCSA Message Exchange. All other intra-agent activity is by message. The MCSA-API is defined at two levels of abstraction: Generic: a system independent description of MCSA Component Message Exchange objects and services, the generic MCSA Message Exchange API Abstraction. System Specific: a mapping of the generic MCSA Message Exchange API Abstraction to a platform specific, system dependent specification for implementation, producing the behavior defined in the MCSA Message Exchange API Abstraction. Although 'C' and 'C++' language syntax are used to define the MCSA Generic Message Exchange API standard and may often be the method for implementation of a systems's API, only the resulting operational effects, as defined by the MCSA Generic Message Exchange API, are mandatory for every MCSA system platform. 3.1 Generic MCSA Message Exchange API Abstraction Overall, the MCSA Message Exchange converts an MCSA System Specific Message Exchange API call into MCSA Message Exchange operations: creating and destroying message queues; and, enqueuing and dequeueing Component Messages. The MCSA Message Exchange posits that byte arrays called messages may be queued to a message queue whose server will then process the messages in FIFO order. Because the MCSA Message Exchange access is through a system specific API, the MCSA Message Exchange services are strictly limited to those message exchange functions that can not otherwise be supported by the message based MCSA Component Dialogue Protocols (i.e. the MCSA Component Dialogue Protocol For Message Queue Services). 3.1.1 Creating and Registering Agent/SubAgentComponent Message Queues Using the MCSA Message Exchange, an Agent/SubAgentComponent creates a message queue and obtains a unique QID, a message queue handle, from the MCSA Message Exchange by issuing a MsgQCreate API call. The MCSA Message Exchange reports to the Agent/Master via Component Message that a message queue is being created; in turn, the Agent/Master registers the message queue through an exchange of messages with the Agent/SubAgentComponent registering the message queue, according to the MCSA Component Dialogue Protocol For Message Queue Services. The Agent/SubAgentComponent may register multiple, system unique, text queue names for a message queue. When a message queue is created, only the Agent/Master may send it messages until the message queue is registered with the Agent/Master. By definition, an Agent/SubAgentComponent instance supports one message queue. It is assumed that the Agent/Master and the implementation of the MCSA Message Exchange come into existence at the same time and that the Agent/Master message queue is registered with the MCSA Message Exchange, a priori, with the queue name "Agent/Master" and a public QID equal to 1. In addition, all Component Dialogue Protocol For Message Queue Services message types are registered a priori. All other message queues must register with the Agent/Master before use. 3.1.2 Sending Component Messages An Agent/SubAgentComponent sends a Component Message to any message queue, including its own message queue or the Agent/Master's message queue, by issuing a MsgSend API call. 3.1.3 Locating Message Queues The MCSA Message Exchange locates a message queue by QID. The Agent/Master, using the MCSA Component Dialogue Protocol For Message Queue Services, supports message queue lookup by first/next message queue or by MsgQueueTextName. 3.1.4 Destroying Message Queues The Agent/Master will continue to forward encapsilated Component Messages to a registered message queue until the Agent/SubAgentComponent issues a MsgQDestroy call to the MCSA Message Exchange API causing the MCSA Message Exchange to send to the Agent/Master an Component Message for that message queue according to the MCSA Component Message Dialogue Protocol For Message Queue Services. 3.1.5 Servicing a Message Queue The Agent/Master and Agent/SubAgentComponents are message queue servers that process the Component Messages queued to their message queue in FIFO order by dispatching their queue server logic after issuing a MsgGet API call. The message is processed according the MCSA Component Dialogue Protocol that defines the message. While the dispatch of queue server logic is a MCSA Message Exchange operation, the execution of the queue server logic to process the message is not. 3.1.6 Message Queue Profile The message queue's profile is not maintained by the MCSA Message Exchange itself. Instead, every message queue server sends, upon receiving a message, a message(s) listing the message types it supports according to the MCSA Component Message Dialogue Protocol For Message Queue Services. A list of the message queue's registered names can be obtained sending a message to the Agent/Master. 3.1.7 Message Type Scope All Component Messages have a message type defined by the relevant MCSA Component Dialogue Protocol or are dynamically assigned by the Agent/Master through the MCSA Component Dialogue Protocol For Message Queue Services and are unique throughout the MCSA/Agent. Each message type is uniquely defined within the MCSA Message Exchange and applies to all message queues, allowing Component Messages from any Component Message Dialogue Protocol to be serviced by the same message queue. 3.1.8 Message And Response Identification When a message is sent by the MsgSend, a unique message id is generated by the MCSA Message Exchange for the message. This message id is placed in the Component Message by the MCSA Message Exchange and is also returned by the MsgSend function to the caller. If the encapsilated message is later forwarded by the Agent/Master to the destination queue, the Agent/Master places the message id into the unencapsulated message before queuing it to the destination message queue. The message id is later used to identify any responses by the placing the message id into the message response id field of the responding message(s). 3.1.9 Served Message Queues When a message queue is created and server logic is provided, the message queue is a served message queue. When a message is queued to a served message queue, the pfnQueueServerLogic is eventually dispatched by the MCSA Message Exchange to service the message. 3.1.10 Utility Message Queues When a message queue is created and no server logic is provided, the message queue is a utility message queue. The intended use of a utility message queues by either the Agent/Master or an Agent/SubAgentComponent is for holding messages within the component. An Agent/SubAgentComponent may have multiple utility message queues. 3.1.11 Authentication MCSA Message Exchange supports authentication of message queue controlling interface calls with the user's queue creator identification, the private QID. 3.1.12 Multiple Processor Discribution If a system's MCSA Agent is distributed across multiple processors which make up the system, then an instance of the MCSA Message Exchange must reside on each processor supporting MCSA message queues. It is within the distributed, platform specific MCSA Message Exchange that inter-processor message exchange takes place, supporting system wide, MCSA message queue access as required by the MCSA Generic Message Exchange Abstraction. The Agent/Master supports its message queue on a processor and any Agent/SubAgentComponent instance supports one message queue on one processor. 3.2 MCSA Message Exchange Generic API Every implementation of an SNMP/MCSA/Agent provides the effect of the following functions: 3.2.1 MsgQCreate QID MsgQCreate ((* pfnQueueServerLogic) (MSG *pMsg)); MsgQCreate creates and registers the component's message queue with the MCSA Message Exchange. The returned its private message queue id (QID) is also forwarded by the MCSA Message Exchange via a message, notifying the Agent/Master of the new message queue's creation. The Agent/Master then registers the QID according the MCSA Message Exchange Dialogue Protocol For Message Queue Services. If the pfnQueueServerLogic is NULL, the message queue is not serviced and is a utility queue; else, pfnQueueServerLogic services all messages sent to the message queue. The QID returned is the private QID known only to the MsgQCreate issuer. And is used only as required by the MsgQDestroy, MsgQCheck, MsgQServe and MsgSend functions for authentication. This private QID is mapped to a public QID by the MCSA Message Exchange when using the message queue's QID (i.e. source and destination addresses in a message). Only the MCSA Message Exchange or its creator may use the private QID. The Agent/Master, as an authenticated component, may delete message queues using its private QID and the subject message queue's public QID. 3.2.2 MsgQDestroy MsgQDestroy (QID qidMessageQueue, QID qidMaster); MsgQDestroy destroys a message queue identified by the private qidMessageQueue. If qidMessageQueue is a served message queue, the MCSA Message Exchange sends a message to the Agent/Master. The Agent/Master processes the request according to the MCSA Component Dialogue Protocol For Message Queue Services, returning all unprocessed messages in the sending message queue and unregistering the message queue. In addition, the MCSA Message Exchange performs the appropriate destroy functions for the QID within any MCSA Message Exchange maintained context. The qidMaster is NULL unless the caller is the Agent/Master, then it is the Agent/Master's private QID and the qidMessageQueue is the subject message queue's public QID. The MCSA Message Exchange dispatches the pfnQueueServerLogic of a served message queue with a NULL MSG pointer, indicating the message queue has been destroyed. Once the MsgQDestroy returns to the caller, the message queue can no longer be accessed by any Agent/SubAgentComponent. Whether the MsgQDestroy returns to the caller before or after the MCSA Message Exchange dispatches the pfnQueueServerLogic of the served message queue is implementation dependent. Returns 0 if success; else, no such queue. 3.2.3 MsgQCheck MsgQCheck (QID qidMessageQueue); The MsgQCheck returns the number of messages in the message queue identified by qidMessageQueue. If the qidMessageQueue is not valid, the value all ones is returned. 3.2.4 MsgQServe MsgQServe (QID qidMessageQueue); The MsgQServe causes a served message queue's pfnQueueServerLogic to be given control, whenever the next message is available in the message queue. Each MsgQServe call services one message. Returns 0 if request accepted; else, bad qidMessageQueue. Whether the MsgQServer returns only after a message is processed or immediately is system dependent. When the message queue is destroyed, the pfnQueueServerLogic is dispatched with the MSG *pointer equal to NULL if a MsgQServe request is outstanding when the message queue is destroyed. If the message queue is destroyed and then a MsgQServe is issued against the message queue, a bad qidMessageQueue indication is returned. 3.2.5 MsgCreate MSG *MsgCreate (int nMaxMessageLength); Creates a message with all required header fields, ready to accept additional fields. Returns MSG * pointing to the message if OK; else, NULL. 3.2.6 MsgDestroy MsgDestroy (MSG *pMsg); Destroys a Component Message by changing the message's signature field to another value, preventing it from being processed as a message by the MCSA Message Exchange. Returns 0 if ok; else, not a Component Message. 3.2.7 MsgSend MSGID MsgSend (MSG *pMsg, QID qidSourceQueue); The MsgSend sends a message, pointed to by pMsg, to the message queue named in the message's destination QID, and returns a MCSA Message Exchange MSGID for the message sent. The MCSA Message Exchange places the MSGID and the public qidSourceQueue into the message before forwarding it. If the destination message queue is a served queue and the sender is an Agent/SubAgentComponent, the MCSA Message Exchange's API MsgSend encapsulates the Component Message into a Component Message that it queues to the Agent/Master's message queue to be forwarded by the Agent/Master. Only the Agent/Master may send a message to a served message queue directly. If the destination message queue is a utility message queue, the MCSA Message Exchange's API MsgSend enqueues the Component Message directly into the utility message queue. 3.2.8 MsgGet MSG * MsgGet (QID qidMessageQueue); The MsgGet dequeues a message from a utility message queue identified by qidMessageQueue. A NULL message pointer is returned if no message is in the qidMessageQueue. If qidMessageQueue is not a utility queue, all ones is returned. 4.0 Message Parsing [Is this essential?] FieldCreate (); FieldGetNext (); FieldAdd (); FieldFind (); FieldDestroy (); ElementGet (); ElementSet (); 5.0 MCSA Inter-Component Message MCSA Component Messages are arrays of contiguous bytes organized into message fields. Each message field has the following field elements, in order: FieldType: identifies the type of field. Every FieldType is unique within the scope of a message's definition. Required FieldTypes common to all messages have the same FieldType value in all messages as possible. FieldLen: gives the length of the FieldData element. If you add the FieldLen to the address of the first byte of the field's FieldData, the result points to the next message field, if any. FieldData: contains 0 to n bytes of data where n is FieldLen value. A field is NULL when FieldData contains 0 bytes. 5.1 Message Header Fields Each MCSA Component Message has a set of required message header fields that determines how each message is constructed and parsed. The following fields always appear at the beginning of every message, in order. 5.1.1 fl_Message_Key_Signature Field FieldType: (sizeof (BYTE)) FieldLen: 2 (sizeof (BYTE)) FieldData: the characters "CM" (sizeof (BYTE * 2)) This field is the message signature field. This is the only field in Component Messages that is always the same. Any expected message not having a correct fl_Message_Key_Signature field is in error and can not be processed as a Component Message by the MCSA Message Exchange. 5.1.2 fl_Message_Key_FieldType_Len Field FieldType: (sizeof (BYTE)) FieldLen: 1 (sizeof (BYTE)) FieldData: the size of the FieldType (sizeof (BYTE)) This field gives the length of the FieldType element for all fields that follow in this message. 5.1.3 fl_Message_Key_FieldLen_Len Field FieldType: FieldLen: 1 (sizeof (BYTE)) FieldData: size of the FieldLen (sizeof (BYTE)) This field gives the length of the FieldLen element for all fields that follow in this message. 5.1.4 fl_Message_Type Field FieldType: FieldLen: variable FieldData: this message's type. The MCSA Message Exchange wide, unique message type defined by a MCSA Component Dialogue Protocol and used to map the message to its own server logic within the pfnQueueServerLogic function. A message type has a message type name that is represented in text in the format as in "", where "" is the defining MCSA Message Dialogue Protocol name, in this case the MCSA Message Exchange Dialogue Protocol For Message Queues and "" is the message name. The notation "<>" means the message's protocol is within current dialogue protocol type definition. Except for Component Dialogue Protocol For Message Queue Services message types, all message types must be registered before they are used as a Component Message's type. 5.1.5 fl_Message_Length Field FieldType: FieldLen: variable FieldData: the message length The is the length of a Component Message. If you add the to the address of the start of message (first byte of the field), you would point to the first byte pass the end of the message. As fields are added and deleted, the value changes. 5.1.6 fl_Message_Id Field FieldType: FieldLen: variable FieldData: message id. The is the unique message id for a message instance. The MCSA Message Exchange sets the message id value when a MsgSend is issued. 5.1.7 fl_Message_Id_Rsp Field FieldType: FieldLen: variable FieldData: the response id The is the response id of the message, identifying the of the message being responded to; NULL if this message is not a response message. 5.1.8 fl_Message_Destination Field FieldType: FieldLen: variable FieldData: the destination QID of the message The is the destination QID of the message. 5.1.9 fl_Message_Source Field FieldType: FieldLen: variable FieldData: the source QID of the message The is the public QID of the message named by the qidSourceQueue of the MsgSend. If the is zero, then the source of the message was a system entity that does not service a message queue and may not be sent a response. (i.e. an interrupt handler, allowing instrumentation to communicate with the MCSA/Agent) 5.2 Non Header Message Fields Any additional field in a Component Message is defined by the message's MCSA Message Exchange Dialogue Protocol. 6.0 MCSA Component Dialogue Protocol For Message Queue Services The Message Queue Services protocol, , describes the message exchange by which the Agent/Master provides message queue management services for Agent/SubAgentComponents that augment the minimum queue services supported by the MCSA Message Exchange through its API. The MCSA Component Dialogue Protocol For Message Queue Services message types exist a priori and the value is indicated by the notation (n) following the message type name (i.e. (1) indicates message type value of 1. The following message definitions include only non header field definitions. Messages may or may not have fields other than message header fields. Please note: often in message definitions, fields are repeated in the response message even though they may also be in the original message which is identified by field. This repetition is designed to aid the Agent/SubAgentComponent's context retention. Within the context of the protocol definition, "<>" is equivalent to "". 6.1 Message Type: (1) The MCSA Message Exchange sends this message to the Agent/Master when a MsgQCreate API call is made by a system component. The message's contains the QID of the created message queue. The Agent/Master responds by sending a <> Component Message to the QID of the just created message queue. 6.2 Message Type: (2) This message is sent by the Agent/Master and requests that the queue's Agent/SubAgentComponent respond by sending a <> Component Message giving a message queue text name under which the Agent/SubAgentComponent wishes to register the message queue. 6.3 Message Type: (3) FieldType: FieldLen: variable FieldData: null terminated text queue name This message is sent by the Agent/SubAgentComponent to the Agent/Master to register a queue text name under the message's source QID. The message queue server must respond at least once to the <> message with this message or the message queue's QID is not registered with the Agent/Master. A message queue may register with no text name by responding with a NULL . This message may be sent again and again to register additional message queue text names for the source QID message queue. In the FieldData, the notation "*" returns a unique queue name selected by the Agent/Master; the notation "*" deletes the "*" and concatenates, to the remaining string, a variable length appendage which makes the queue name unique among all registered queue names. 6.4 Message Type: (4) FieldType: FieldLen: variable FieldData: null terminated text queue name FieldType: FieldLen: variable FieldData: null terminated text queue name This message is sent by the Agent/Master to the Agent/SubAgentComponent. It returns the queue text name registered under the destination QID. 6.5 Message Type: (5) FieldType: FieldLen: 4 FieldData: target message queue's QID. This message requests the Agent/Master respond with <> message that lists the message queue text names registered under the . 6.6 Message Type: (6) FieldType: FieldLen: 4 FieldData: target message queue's QID. FieldType: FieldLen: variable FieldData: null terminated text queue name (repeated n times) This message is sent by the Agent/Master to the AgentComponent listing all message queue text names a message queue under which it is registered. The complete list may be in one or more messages sent in reply. The end of item list is indicated by a NULL in the last response message. 6.7 Message Type: (7) FieldType: FieldLen: variable FieldData: null terminated message queue text name to find. FieldType: FieldLen: 4 FieldData: current QID in list. This message requests the Master/Agent respond with a <> message returning the QID of the message queue whose name matches the search queue name, or NULL if no registered message queue had that name. If the fl_CurrentQueue is NULL, the search begins from the beginning of the registered message queue set. If the is NULL or "*", the next QID in the registered set is found. Wild card notation (*,?) is supported and returns the first instance found to satisfy the search argument. 6.8 Message Type: (8) FieldType: FieldLen: variable FieldData: null terminated message queue text name to find. FieldType: FieldLen: 4 FieldData: QID of found message queue. This message is sent by the Master/Agent to the Agent/SubAgentComponent in response to a <> message. 6.9 Message Type: (9) FieldType: FieldLen: 4 FieldData: target message queue's QID. This message is sent by the MCSA Message Exchange, in response to a MsgQDestroy API call, to the Agent/Master to delete the message queue from the Agent/Master's set of registered message queues. Any Component Messages remaining in the message queue are returned to the message source by the Agent/Master, then all contexts within the Agent/Master for this QID are terminated. 6.10 Message Type: (10) FieldType: FieldLen: 1 FieldData: return reason code (1 = message queue does not exist 2 = message queue destroyed 3 = msg type not supported) FieldType: FieldLen: variable FieldData: encapsilated message This message is sent to the message sender if the message can not be processed. 6.11 Message Type: (11) FieldType: FieldLen: variable FieldData: encapsilated message This message is sent by the MCSA Message Exchange to the Agent/Master in response to a MsgSend API call by the Agent/SubAgentComponent. The Agent/Master checks the destination QID of the encapsilated message. If the QID is a registered message queue, the encapsilated message is forwarded to the destination QID message queue. If the destination QID is the Agent/Master itself, the message is processed by the Agent/Master. If the encapsilated message is not supported by the message queue, that is it contains a message type can not or should not be queued to the destination QID message queue, the encapsilated message is returned to the source QID message queue with a <> message. [The following message_type_support messages are intended to support the coexistence of both protocol defined message types and Ad Hoc message types. As in many parts of this document, there should be a better solution than the one proposed; I just could not think of it.] 6.12 Message Type: (12) FieldType: FieldLen: variable FieldData: text name of a message type to be registered FieldType: FieldLen: variable FieldData: message type to be registered This message is sent by an Agent/SubAgentComponent to the Agent/Master to dynamically obtain message types, including those defined in mandatory RFCs. The registration message is compared against a registered message type list maintained by the Agent/Master, each list item consisting of a and . If neither the message's nor are in any Agent/Master's message type list entries, a list entry is created, registering the message type. If both the message's and are in the same list entry, the response indicates the message type is "already registered". If the message's is not in the message type list and the message's is zero, the and a , dynamically assigned by Agent/Master, are registered, returning the and a response status of "ok". If the message's is in the message type list and the message's is zero, the is returned with a status of "already registered". Message types defined in mandatory RFCs are always registered with their RFC defined ; Ad Hoc message types of Ad Hoc protocols, not defined in mandatory RFCs, are always proposed arbitrarily. The first character of an RFC defined name is "<" and the last character is ">"; Ad Hoc message type names may not have these first and last characters. Ad Hoc message type names, hopefully, migrate to RFC defined name space with the prefix "<" and suffix ">", so that one, Ad Hoc name, predicts the other, RFC defined later. message types are registered a priori at the startup of the MCSA Message Exchange. 6.13 Message Type: (13) FieldType: FieldLen: n bytes FieldData: return status 0 = ok; 1 = already registered 2 = message type in use 3 = message name in use 4 = syntax error FieldType: FieldLen: variable FieldData: text name of a message type to be registered FieldType: FieldLen: variable FieldData: message type dynamically assigned This message is sent by the Agent/Master to Agent/SubAgentComponent in response to a <> message. The status "syntax error" means the <> message fields were incorrect. 6.14 Message Type: (14) FieldType: FieldLen: variable FieldData: message type Message sent by Agent/SubAgentComponent to Agent/Master to locate a message type by name. 6.15 Message Type: (15) FieldType: FieldLen: variable FieldData: message type FieldType: FieldLen: variable FieldData: text name of a message type to be registered If the FieldData is NULL, the name was not found in the Agent/Master's message type list. 6.16 Message Type: (16) FieldType: FieldLen: variable FieldData: text name of a message type to be registered Message sent by Agent/SubAgentComponent to Agent/Master to locate a message name by type. 6.17 Message Type: (17) FieldType: FieldLen: variable FieldData: text name of a message type to be registered FieldType: FieldLen: variable FieldData: message type 6.18 Message Type: (18) This message is sent to any message queue server to obtain the message types this message queue services. 6.19 Message Type: (19) FieldType: FieldLen: variable FieldData: a message type supported (repeated n times) This message is sent in response to a <> message by the message queue server. The complete list may be in one or more messages sent in reply. The end of item list is indicated by a null message type in the last response message. 6.20 Message Type: (20) This message is sent by an Agent/SubAgentComponent to the Agent/Master to indicate that message registered types are now supported or no longer supported by the Agent/SubAgentComponent's message queue. The Agent/Master reacts to this message by sending a <> message to the Agent/SubAgentComponent queue server to obtain the message types this message queue supports. 6.21 Message Type: (21) This message is sent by an Agent/SubAgentComponent to the Agent/Master to get the message queue's public QID. 7.0 MCSA Message Dialogue Protocol For Time This protocol provides an Agent/SubAgentComponent with time services. 7.1 Message Type: This message is sent by a Agent/SubAgentComponent to the Agent/Master to obtain the SystemUpTime. 7.2 Message Type: FieldType: FieldLen: variable FieldData: system up time Message sent by the Agent/Master to the Agent/SubAgentComponent or Agent/Master in response to a <> message. 7.3 Message Type: This message requests the Agent/Master's current time be sent in reply. 7.4 Message Type: FieldType: FieldLen: variable FieldData: current system time This message is a response to a <> message and returns the current Agent/Master's system time. 7.5 Message Type: FieldType: FieldLen: variable FieldData: system up time FieldType: FieldLen: variable FieldData: first byte of the encapsilated message This message sets a time when to forward the encapsilated message to its destination of QID. 7.6 Message Type: FieldType: FieldLen: variable FieldData: time interval for tick. FieldType: FieldLen: variable FieldData: id of tick requested. This message is sent by any queue server requesting a <> message at the interval specified until the receipt of a <> message. 7.7 Message Type: FieldType: FieldLen: variable FieldData: time interval for tick. FieldType: FieldLen: variable FieldData: Id of tick request This message is sent by the Agent/Master to the tick requestor's message queue each fl_TickInterval until the receipt of a <>