RACE - Modifications and Extensions to ACE from Ravensburg

Further Ideas

Using the Proreactor-Pattern

For Systems which have a Asynchrounous IO the Proreactor-Pattern is a good idea. The Logger-Thread is then the Devicedriver itself.

In the Proactorpattern the Logger fullfill the role Initiator and Competion Handler.

In 2003, on Linux 2.4., the libc emulated the Asynchronous IO. Thus we decided to do it ourself.

RACE_Logger as interface

RACE::Logger may become an abstract interface with a few implementations:

Syncronous Simple Logger: Puts the Dumpables simply in the Accumulator in the same thread
Active Logger: Logger with Active Object Pattern - the current
Proreactor-Logger: like described above

Reusing Memory for the `RACE_Message_Block`s

We have to cases: the Memory for the persistent data in RACE_Datablocks and the memory for the transient Accessordata in the RACE_Message_Block.

The persistent Data in RACE_Data_Blocks

Since the Introduction of the RACE_READER, the RACE_Data_Blocks are produced by an RACE_Data_Block_Factory. (Done in RACE-1.1)

The transistent Data in the RACE_Message_Blocks

Currently, the Memory for the RACE_Message_blocks is manged by the new and delete-Operator.

A better idea would be to have Memory-Pools for the RACE_Message_Blocks in a Factory. This factory could do a efficent recycling of not more needed RACE_Message_Blocks, since the size of the management data is always the same.

Memory Manegement for the transient data of RACE_Message_Blocks

A RACE_Message_Block have the following usage pattern in the read-case:

The data is read from an device
The data is interpreted. For this purpose, iterators and other transient constructs are created.
The message will be consumed in an specific way and further actions will be done.
The message memory-resources will be freed.

In the write case:

the message will be constructed. For this purpose, iterators and other transient constructs are created.
The persistent message data will be written to an device.
The message memory-resources will be freed.

(Idea: writing of usage-patterns) Common in both cases the memory is freed at once. Effizient memory-management will be with a memory allocator for the RACE_Message_Block. When the message-block will be deleted, the whole resources of the memory-allocator are released at once. The second benefit is that all the memory will be kept together. Thus the working set in a paging operation system is minimised and this will be optimal in performance.

Scatter-Gather at protocoll Stacks

During the way down in a protokoll stack a packet must be enhanced with the heder of the corresponding layer. For more performance, we must avoid copying.
There are two possibilities:

Fragmented RACE_Message_Block: Each header is in its own RACE_Data_Block.
This has the advantage that theRACE_Data_Block can point to a mapped memory page (for example of a RAMS-Segment, which has to be seen contiguous for the user).
Enought Place in front of the RACE_Data_Block: This has the advantage to avoid the memory allocation.

In future the RACE_Message_Block could have the Operations head() and tail() which points on the Message_Bock content and correspondig operations to enhance the area. If no mor space in that area, a new fragmet RACE_Data_Block could be allocated automaticaly.

Types

Currently, the Types of the Dumpables are integers. It is a task for the application programmer to select them (may a hash value or an simple enumaration).
An other Idea is to use CORBA-Typecodes for that.
RACE::ReadBuffer and RACE::Interpreter must be slightly modified for this.
To read and process arbitrary logfiles tcpdumps with the RACE-Reader a more generic seperation is nessaccary.

Messagestore

A Messagestore for Store and forward-Messaging (multicast or not) could be implemented with RACE.
The queuing in the Logger should handle short bursts of high frequency.

Computerscience and Networkassocation Ravensburg e.V Rudolf Weber and friends