The ORB directs requests to servers based on the Service Type needed and directs the server's responses back to the original requestor.    Like a traffic policeman, the ORB is capable of directing traffic to a specific destination and it controls the flow of traffic balances loads and can marshal mulitple part requests (this is not multi-packet).   

All ORB communication is via message layer (msg) but the Orb uses some low level I/O to handle multi-packet queries and responses.    Four Msg field names are reserved for use by the ORB, they are: "type", "code", "status" and "reqId".    The "type" field determines the service type required, the "code" determines, to the server, exactly what function to perform.    The "reqId" field is used by the ORB (much like a session) to match responses to requests.    A client initially builds a request with "type", "code", "status", and "reqId" integer fields ("reqId" is initially zero but MUST be present).    These fields are provided automatically by the Msg calls to create requests (msgMkReq), and responses (msgMkRsp).    Two "code"s are reserved for the ORB, 1 is a server read, and 2 is a server response.    Types and Codes are defined in "orb.h".    The Orb uses a Request - Response protocol, that is, every Request has a Response, and the requestor must wait for the response.    If a client makes a request, it MUST wait for the reponse.    If a client makes multiple requests without waiting for respnoses and then exits, any un-assigned requests will be cancelled.    All requests between the Orb and clients or servers are always acknowledged (ACKed) either after the request is complete or immediately, depending upon how the Orb is configured for that service type.    When a server is assigned a task, the Orb sets it's status to busy until the server returns a response, or dies.    Upon boot up, each server must register it's service type with the Orb, whereupon the server becomes available for service request assignments.

Client & Server operation:
A request must contain correct type and code, with status and reqid set to zero.    The response will contain the same type field, the code set to "response", and status and requid set appropriately.    A server must capture the reqid and return it with the response so that the ORB may match the request id of a response to the original request.    Two "codes" are reserved, 1: a server registration, and 2: a response.    A support module is available for building servers called appSrv.

ORB operation:
Received requests are classified, by type, which determines whether to immediately ACK to the requestor or delay.    The type also determines if the request is immediately ready for assignment or must be marshaled.    The request may terminate a marshaled set of requests by making it ready for assignment (dispatch).    When a ready request and a ready server of the same type are found, the request is forwarded to the server, and the server and request are both marked busy.    If an immediate ACK is issued to a requestor of a certain type, that type is thought of as "Fire and Forget".    Most requests are forwarded to an available server and the server's response forwarded back to the requestor.

Marshaling is the ability to treat a set of request messages as a single request.    A set is determined by matching the content of a named field in each message.    The field name is determined by the ORB's configuration.    The message which terminates the set must have a unique "code".    If a request of a "type" defined as marshaled arrives but does not contain the set field, it is reported as an error.   

Load balancingis done by maintaining the ready/busy status of servers and assigning new incoming requests to available servers (not busy).    A server is marked busy when a request is assigned to it and available when the service is complete.    Since most server systems perform bests when re-using hot pages in memory, sporadic requests will be assigned to the most recently used server.   

The ORB is capable of managing servers distributed across many physical CPUs and accepting requests from clients on other machines.   

Client and Server crashes are monitored by the ORB so that a request may be re-assigned if it's server crashes, and a request is aborted if it's requesting client dies.    In the event multiple servers (3) crash while servicing the same request the request is determined to be poisoned and returned to it's origin with an error status.   

Servers may return multi-packet results. Each non-terminal message packet will contain a Data To Follow MO flag bit.    This feature is handled invisible by the ORB and the msg facility   

If a request arrives and no server is available the request will be queued by the ORB until an appropriate server is available.   

The ORB is capable of reliable queuing (caching), as determine by request type, an arriving request will be written to a hard disk cache and the requestor ACKed immediately.    The request remains in the hard cache until it's servicing is complete.    When an ORB is started it reads the hard cache from disk and builds the appropriate request / type chains so that when servers report in, they are immediately assigned.   

Real-Time statisticsare maintained by the ORB for each type. These include Min, Average, and Maximum service and in-queue times along with arrival rates and request counts.   

Using the ORB: The two most common ways to talk to an ORB are as a server or client.    As previousle stated, the ORB speaks only in Message Layer calls, hence all clients and servers must communicate using the Msg layer calls.   

An ORB Client must create a request Msg, containint the desired integer "type", "code", and a zero value "reqId" and "status" fields, additionally, such request information as is required by the desired service "type" server.    A handy way to create the request is via msgMkDst(), then msgSnd(), and finally msgRcv().   

An ORB Server must send a Msg with the integer fields "type" = ServiceTypeSupported, and "code" = SRV_READ message to the ORB at the server's initialization.    The server must then wait for a service request from the ORB.    Upon receiving a service request, the server must save the "type", "code", and "reqId" fields.    The server must next extract any specific request information fields from the message and proceed with processing the request.    When processing is complete, the server should build a response message Msg and insert the saved "type", "code", "reqId", and a new "status" field (this is handled automatically by msgMkRsp().    The status should contain an infrastructure OK (1 one), a NOTFND (zero), or an error (negative value).    An error message may contain the field "errMsg" which is a string explaining the situation causing the error.    This message should tben be sent to the ORB and the original request message freed.    Again the msg layer of the infrastructure provides a good way to handle all messaging using: msgMkDst() (initial SRV_READ), msgSnd(), msgRcv(), msgMkRsp(), and msgFree().   

It is possible to use multiple Orbs in a single system to accomplish a variety of chores.    The difference between Orbs in a multi Orb system is determined by which Orb the server processes register with.   

The blkr (Blocker, an IPS) consists of two Orbs, the blkr, multiple device drivers and the CryptoCache.    Note the Blkr and all device drivers use the appSrv layer which always looks for the "BROKER" config keyword as it's registration Orb.    Hence, in the Blkr stanza BROKER = Orb and in the device driver stanzas BROKER = ORB2.    The Blkr gets requests to block and unblock specific IPs or CIDRS from either the web or analysis programs via the Orb, then uses Orb2 to request blocking service of a certain Type from the device drivers.   

The Blkr registers as a server with the main Orb, while it's device drivers register as servers with Orb2.    This allows blocking requests from the web and analysis programs to reach the Blkr and for the Blkr to access it's device drivers using their service Type as the device type.    Note the Blkr code uses Orb2 to make blocking requests and the device drivers use Orb to access resources like the CryptoCache.    Under the covers the individual device driver service Type is used to determine which blocking device type.    Hence you can have multiple CiscoRouter device drivers to handle multiple requests, etc.