-
Notifications
You must be signed in to change notification settings - Fork 0
Developer guide
The broker is a modified version of HiveMQ Community Edition so most of it's documentation could be relevant.
HiveMQ Community Edition contains a module called com.hivemq.configuration which is responsible for loading configuration data at startup. In it's subpackage, entity, the XML element types are defined. The priority element is defined in TopicPriorityEntity. The class ConfigFileReader reads an XML file and the maps the XML entities to the right configurator. The class TopicPriorityConfigurator is responsible is responsible for converting the XML entities into usable configuration state and setup an instance of the TopicPriorityConfigurationService interface. This interface only has one concrete implementation, TopicPriorityConfigurationServiceImpl. This service is used for interacting with the configuration, it can provide a list of all TopicPriority instances configured with the function getPriorities()
The prioritization of messages is done with the help of a priority queue and the PublishComparator class. This is used in the class ClientQueueMemoryLocalPersistence which temporarily stores all incoming messages before sending them to the subscribing clients. The comparator looks up the priority of the given publish messages and compares the priority class and number.
The broker will mark outgoing traffic with the DS value corresponding to the publish message's priority. This use done with Netty's implementation of setTrafficClass in the MQTTMessageEncoder class.
Our MQTT Client library is a modified version of HiveMQ MQTT Client. It has all of the original functionality with some additions. We have among other things changed the ClientBuilder interface to allow for setting topic priories. New java files can be found in the package com.hivemq.client.extensions.
The test application is a CLI tool written in Kotlin with the use of Clikt. It contains standard MQTT actions such as subscribing to topics and publishing messages. It also contains a way to performance test multiple topics and generate statics based on the tests.
The CI/CD is setup to check the code of the client and the broker. It will also build Docker images for the broker and the test app. These are published to DockerHub with the names tokongs/ffi02-broker and tokongs/ffi02-test-app respectively. When a new broker image is published the workflow will also run a script on the Azure VM to pull and run the latest version. The machine is accessed with SSH and a Github Secret. If changing the machine the secrets containing the address and access information needs to be updated.