-
Notifications
You must be signed in to change notification settings - Fork 1
Problem Statement
The following shortcomings have been identified by looking a the currently available messaging systems and the current version of the GNUnet-MQTT protocol.
Classical architecture use a central message broker that routes all the messages transmitted within the system. This has a few downsides.
The broker as the main hub is a central point of failure. If the broker is not available all the connected peers can not exchange information anymore.
Unfortunately brokers offer a large attack surface for degration/denial of service attacks
- malicous subscribers could simply flood the broker by transmitting a large amount of packets
- the broker could be forced to transmitt unecessarily often by subscribing to all the messages exchanged by the broker
- bot networks could open a large amount of connections to the broker and thus overloading it
As the central point of communication the broker is also a honeypot for compromising the confidentiality of the exchanged messages. Wrong access control lists could allow for message routing to untrusted clients. The broker itself could also read the exchanged messages, or at least have a complete log of meta-data of the communication.
Current high performance brokers can handle up to a couple of thousand (maybe 100) simultaneus connections while still allowing for decent message latency. However growing any further than this is not feasible for most systems.
Furthermore, because of the high hardware requirements, a single individual with access to standard commodity hardware can not run such a broker for a large scale message distribution.
The current GNUnet-MQTT code as of SVN revision 34124 aims to solve one of the most pressing issues of classical messaging, it allows every GNUnet-Peer to be broker and thus eliminates the central point of failure.
However the source code in unmaintained for quite some time so that it does not even build with recent versions of GNUnet.
Furthermore it is not compliant with the MQTT v3.1 specification in various aspects. For example it does not offer MQTT-clients to connect to GNUnet-MQTT because the API and wire-format of the data is different from the specification. It also lacks the support for core feature of MQTT such as retained messages.
The way how GNUnet-MQTT is implemented right now is that it uses GNUnets REGEX module. Subscribers interested in certain topics first convert the topic into a regular expression an then announce the regular expression and their Peer ID through the GNUnet-REGEX API.
A Publisher on the other hand performs a GNUnet-REGEX search to obtain Peer IDs of peers where his topic matches their regular expression. He then sends them his publications directly using GNUnet-MESH.
This has the following negative effects
- There is no privacy, a simple search can be used to obtain the preferences/subscriptions of any Peer
- It does not scale well as the current transport mechanism force the publisher to send one message per subscriber
- There is no Authentication or Access Control, anyone can subscribe to any topic. Also the subscriber can not select which publishers he wants to follow, anyone can send him his messages and he has to filter afterwards
- Adoption and use of GNUnet-MQTT are seriously limited since regular MQTT clients can not connect to a GNUnet-MQTT Peer.
In this project the following problem of GNUnet-MQTT where addressed and fixed
- Fixing GNUnet-MQTT to work with recent versions of GNUnet
- A novel way of discovering publishers, while still maintaining subscription privacy was designed and implemented
- The transport mechanism of GNUnet-MQTT was replaced scalable multicast based transmissions to enable individual peers to handle a large subscriber base
- Subscribers can now choose which publishers they want to follow and connect to