TraceServer
  • Dcodes IIOP packets
  • Processes the data

General

The components Decoder, Frontend and Backend are all implemented in a common, second process. Within this process, though, they are considered strictly distinct entities. While the Decoder component plays a central role using the functionality of both Front- and Backend, the main control logic is placed outside these components within the Coordinator. The responsibility of the Coordinator is to control the connection setup and teardown to the Sniffer as well as the inititialization and parameterization of the system as a whole. This includes the creation of Front- and Backend instances, whiiich are in turn assigned to corresponding decoder instances. Once a connection to a Sniffer has been established successfully, the Coordinator creates a decoder instance which finally services all requests that are transferred over this connection.

Decoder

The ultimate purpose of the Decoder implementation is to decode the data packets coming from the Packet Sniffer as far as possible. To achieve this goal, the Decoder needs the functionality of Frontends. The decoded infomation is forwarded to Backends for final processing. A Decoder can be assigned several Front- and Backends. In this case, all Backends assigned will receive all of the data extracted.

The core part of the DDecoder is the IIOP Engine. It is a re-implementation of a previous version that was based on the SunSoft IIOP Engine. The new IIOP Engine is capable of decoding GIOP 1.1 (which implies support for GIOP 1.0). It offers methods for the encoding and decoding of the GIOP base types from the Common Data Representation, the format used by CORBA for communication 'on the wire'. Encoding and decoding complex types must be supported by external type descriptions. The CDR engine uses a type description buffer which contains the GIOP representation of the type code of the corresponding type. This type code buffer describes the composition of a nested (complex) type from the base types. The decoding of a complex type is is done by sequentially decoding these base types. The typpe information necessary for the decoding are provided by the Frontends.

The processing of fragmentation type IIOP messages (GIOP 1.1) is implemented internally by storing the fragment messages in lists. Decoding will not start until the last message part has been received, i.e. the IIOP message is complete. It must be ensured that the lists are periodically checked for old fragments since it cannot be guaranteed that all fragments are received for every message.

For GIOP/IIOP, only request type messages contain the method name in the header and all subsequent messages referring to this method do so by means of a RequestID. Therefore, a list kept internally which stores the mapping of method names to the ID must be updated with every request that is encoded. The ID is assigned by the ORB and is not always unique because the environment the TraceServer is used in need not necessarily be homogeneous. To overcome the resulting ambiguities, the connection data of the IIOP request are added to the mapping list entries. The mapping list just described must be globally accessible to all Decoder instances.

After a reply type message has been received, the list entry can be removed again. Because it cannot be guaranteed that all messages are received, an aging algorithm must be applied additionally to prevent resource leaks or erroneous mappings for long-running sessions.

When several Backends are assigned to a Decoder, all data is passed sequentially to all Backends.
When several Frontends are assigned to a Decoder, they are polled in the order in which they were passed to the Decoder. The first Frontend that is able to yield the information requested will be used. If an interface cannot be identified unambiguously by a Frontend and there is more than one method matching the name in the internal list, the Frontend will provide a list of alternatives. The decoder verifies these, attempting a decoding. All alternatives will be passed on to the Backends, including the decoded parameters, if appropriate.

The Decoder can store previous successful mappings of interfaces and object keys internally. An object is regarded as identified when it was referenced by a method which can be assigned to a single object only or for several alternatives only one of them leads to a successful decoding.

Image Preview TraceServer Architecture
Image Preview: TraceServer Architecture

Front- and Backends

The strict encapsulation of Front- and Backends allows for extensibility of the Tracer by new implementations of these modules.
Integrated is a Frontend which can read IDL files directly to use them as information source and a second one that makes use of the contents of an Interface Repository. The implementation of the latter is CORBA conformant and can thus interact with the Interface Repositories of all conformant ORBs.
Two variants of Backends are provided. One generates an (encoded) one-line summary from all data available, printing it on the terminal during runtime. The other writes all the data, formatted, to a log file.

Interfaces

All of tthe modules of the TraceServer are implemented in C++. The interfaces between the components are described by the interfaces exposed by the classes. A virtual base class is used for the Front- and Backend, respectively, which defines the interface expected by the Decoder. Custom Front- and Backend classes must be derived from these base classes.