Develop a system adapter
This article is a tutorial to write a system adapter for an existing system that should be benchmarked inside the Hobbit platform. It is recommended to read the overview article before reading this tutorial. Additionally, the general hints on components should be read. If the system adapter will be developed in Java, there is a more detailed tutorial how this development can be supported by using the HOBBIT core library.
The API the system (or system adapter) has to offer to interact with the Hobbit platform is defined as follows.
- It has to use the hobbit session id and RabbitMQ host name that are available as environment variables.
- It has to be connected to the command queue
- After the system is started, it has to initialize itself. At the end of the initialization, the system has to send the
Commands.SYSTEM_READY_SIGNAL
id (=0x01
) on the command queue. - It has to listen to the command queue and should react on the
Commands.TASK_GENERATION_FINISHED
id (=0x0F
). - It has to implement the API of the benchmark with which it should be benchmarked. Note that this API can vary and should be described in more detail by the benchmark. Typically, the API looks as follows.
- The system might connect to the
hobbit.datagen-system.<sessionId>
queue to receive data. - The system has to connect to the
hobbit.taskgen-system.<sessionId>
queue to receive tasks. - The system has to connect to the
hobbit.system-evalstore.<sessionId>
queue to send its result to the evaluation storage. - All three queues follow the work queue pattern and have to be setup with
- their queue name (
<sessionId>
has to be replaced with the current session id), durable = false
exclusive = false
autoDelete = true
- and no additional arguments
- their queue name (
- The system might connect to the
The typical messages of the different queues are described in the following.
The structure of messages in the data queue is solely defined by the benchmark.
Every task has a unique id that is used to map the task to the response that the system created. That means that a message in the task queue always should contain an id that has to be sent to the result queue together with the result.
start byte | length | meaning |
---|---|---|
0 | 4 | task id length as 32 bit integer (t) |
4 | s | task id |
s + 4 | 4 | data length as 32 bit integer (d) |
s + 8 | d | data |
The task id is a UTF-8
encoded String. However, it does not have to be encoded and can be user as byte array for the message that has to be sent to the result queue. The data is a byte array and its content/meaning is solely defined by the benchmark.
The result of a task has to be sent to the result queue together with its task id.
start byte | length | meaning |
---|---|---|
0 | 4 | task id length as 32 bit integer (t) |
4 | s | task id |
s + 4 | 4 | data length as 32 bit integer (d) |
s + 8 | d | data |
The data is a byte array containing the result as it is defined by the benchmark.