Client/Server.

The design of the communication interface between the display client and the analysis server takes into account the following requirements:

• Asynchronous/Interleaved communication. It is possible to trigger multiple requests without actually waiting for the response in order to hide latency whenever multiple instances of the display client make requests for new data.
• Data transformation/preparation. To minimize communication overhead, the data transferred between the two components is not raw event data like what is typically handled by visualization programs. It is important to stress here that the communication volume must not become dependent on the amount of actual event data being processed by the analysis server.
• Endian conversion. The display component and the analysis component typically would not reside on the same platform, or even on the same platform architecture. Conversion of data types to identical endianess therefore is supported.
• Security. Sensitive data might be transferred between the analysis server and the display client. Our interface allows encryption/authentication via standard mechanisms like SSL, ssh tunneling, or similar, even though this can be in contradiction to latency and throughput optimization.
• Extensible interface, compatibility. The interface design takes into account future components transferring data over the same link. Communication between different versions of VNG is possible within the limitation of supported features on both sides.

Based on the above requirements, we identified four different layers of communication to be designed and prototyped:

• Data exchange layer (sockets, shared memory, etc.)
• Endian conversion layer (for inter-architecture communication)
• Serialization packaging layer
• Custom request/response layer

The first layer realizes the pure data transfer by means of simple input and output character buffers. Adapting this layer is sufficient to support different means of communication like sockets, shared memory, etc. Only a very basic API is provided at this layer. On top of this layer type, endian conversion is provided. Data types like float, int, char, string and vectors of them are supported. The third layer is responsible for serialization and packaging of requests and responses. Request and responses are in a format that easily allows adding and removing parameters without loss of compatibility. We therefore used a key word based parameterization for both requests and responses. This final fourth layer is the actual API to the application developer. This interface allows easy request/response generation from and to the analysis server.

We have not tackled the security aspect in this layering approach. We did not want to invent our own security scheme here, but instead we made use of standard ssh tunneling techniques that guarantee proper authentication as well as the encryption of exchanged data. Of course, this layer can be disabled if performance is an issue.