Eclipse Mosquitto

What is Mosquitto?

Eclipse Mosquitto is an open-source MQTT broker maintained by the Eclipse Foundation. Written in C, it is designed to be small, fast, and deployable on virtually any platform - from a full Linux server down to a Raspberry Pi or a resource-constrained embedded gateway. Mosquitto implements MQTT protocol versions 3.1, 3.1.1, and 5.0.

Originally created by Roger Light in 2009 and donated to the Eclipse Foundation, Mosquitto is one of the most widely deployed MQTT brokers in the world. Its combination of a minimal footprint, permissive EPL/EDL dual license, and a simple, well-documented configuration format makes it the default choice for edge deployments, development environments, and small-to-medium production workloads - including RFID reader gateway installations.

How it works

Mosquitto operates as a single-threaded event loop using non-blocking I/O. All client connections, message routing, and protocol state are managed within a single OS process:

• Event loop: Mosquitto uses a select/poll-based event loop to handle multiple simultaneous client connections without spawning threads per connection. This keeps memory overhead low and avoids thread synchronisation overhead, at the cost of capping throughput on multi-core hardware.
• MQTT protocol support: All three active MQTT versions are supported - 3.1, 3.1.1, and 5.0. Clients using different versions can connect to the same broker simultaneously. MQTT 5.0 features such as message expiry, user properties, and shared subscriptions are available when both client and broker negotiate version 5.0.
• Persistence: Mosquitto can write session state and queued messages to a binary persistence file (mosquitto.db). On restart, retained messages, persistent client sessions, and in-flight QoS 1/2 messages are restored from disk, preventing data loss across planned or unplanned broker restarts.
• Bridging: Mosquitto supports MQTT bridging - a broker-to-broker connection where messages on selected topics are forwarded from one broker to another. This is the mechanism used to link an edge Mosquitto instance to a cloud broker, enabling a store-and-forward topology where the local broker queues events if the WAN link is temporarily unavailable.
• TLS/SSL: Mosquitto supports TLS 1.2 and 1.3 for transport encryption, with optional client certificate authentication. Separate listeners can be configured for plain TCP (port 1883), TLS (port 8883), and WebSocket (port 9001 or 8080) connections simultaneously.
• Authentication and ACLs: Mosquitto ships with a password file authenticator and a simple topic-based ACL file. For more advanced requirements, an external authentication and authorisation plugin interface allows integration with databases, LDAP, or custom token systems.

Mosquitto in RFID and IoT

Mosquitto's small footprint and easy deployment make it the most common broker choice at the edge in RFID infrastructure:

• Edge gateway broker: A Mosquitto instance running on the same machine as an RFID middleware layer (or directly on a Linux-capable reader gateway) collects tag read events from multiple readers on a site. Downstream services on the same LAN subscribe to the local broker without any WAN dependency. This pattern tolerates internet outages gracefully - reads continue to accumulate locally and are bridged upstream when connectivity is restored.
• Collecting reader events: Readers that support MQTT output (Zebra FX-series, some Impinj configurations via middleware) publish tag reads to the local Mosquitto broker. Each reader is assigned a topic namespace such as site/warehouse-a/reader/dock-3/reads. A single Mosquitto instance can aggregate dozens of readers without meaningful resource impact.
• Raspberry Pi deployments: Mosquitto is a first-class package in Raspberry Pi OS and can be installed with a single apt install mosquitto command. A Pi running Mosquitto alongside a lightweight RFID middleware agent is a cost-effective edge broker for a small-to-medium deployment - a single rack shelf or a store back-office setup with a handful of readers.
• Bridging to cloud: Mosquitto's bridge configuration connects a site broker to AWS IoT Core, HiveMQ Cloud, or any standards-compliant cloud MQTT endpoint. Topic remapping in the bridge config allows local topic hierarchies to be translated to the cloud namespace without changing reader firmware or middleware. QoS and clean-session settings on the bridge control queuing behaviour during outages.
• Development and test environments: Mosquitto running in Docker is the standard MQTT broker for local development. RFID application developers use it to simulate reader events, test subscription logic, and validate topic structures before deploying to production brokers.

Configuration

Mosquitto is configured via a plain-text mosquitto.conf file. The following covers the key directives relevant to RFID deployments:

• Listeners: Each listener directive opens a port. Multiple listeners with different protocols can run simultaneously - plain MQTT on 1883, TLS on 8883, and WebSocket on 9001. Each listener can have its own authentication settings.
• Authentication: password_file points to a file generated by the mosquitto_passwd utility. Setting allow_anonymous false enforces authentication for all connections. Per-listener overrides allow an unauthenticated listener on loopback (for local middleware) while requiring credentials on the network-facing listener.
• ACLs: acl_file points to a file defining which users can publish or subscribe to which topic patterns. Patterns support the # and + wildcards. A typical RFID ACL grants readers publish-only access to their own topic namespace and grants backend services subscribe-only access.
• Bridge configuration: A bridge is defined with connection <name>, address, topic mapping directives, and TLS settings. The try_private false and cleansession false options control reconnect and queuing behaviour. Topic directives specify direction (in, out, both), QoS, and optional local/remote prefix remapping.
• Persistence: persistence true enables the database file. persistence_location sets the directory. autosave_interval controls how frequently dirty state is flushed to disk - lower values reduce data loss on crash at the cost of more frequent I/O, relevant on SD card based Pi deployments.
• Logging: log_dest directs log output to stdout, a file, or syslog. log_type controls verbosity - common choices are error for production and debug for tracing message flow during commissioning of a new reader or bridge connection.

Advantages

• Tiny footprint: The Mosquitto binary is a few hundred kilobytes. Memory consumption at idle is typically under 5 MB, and it scales to thousands of connections with modest RAM. This allows it to run alongside other software on constrained edge hardware without contention.
• Runs on embedded and edge devices: Mosquitto is packaged for Raspberry Pi OS, Debian, Ubuntu, Alpine, and most major embedded Linux distributions. It runs on ARM, x86, and MIPS. If a device runs Linux and has a network stack, Mosquitto can almost certainly run on it.
• Battle-tested: Mosquitto has been in production use since 2009. The codebase is mature, the Eclipse Foundation maintains active security response, and CVE history is thin relative to the deployment footprint. For edge infrastructure expected to run unattended for years, this stability matters.
• Easy to deploy: A minimal working configuration is a few lines. The mosquitto_passwd and mosquitto_pub/mosquitto_sub utilities ship with the package, providing immediate tooling for testing and administration without additional installs.
• Docker support: The official eclipse-mosquitto Docker image is small (Alpine-based, under 10 MB) and widely used. Volume-mounting the config and data directories makes it straightforward to run Mosquitto in containerised edge infrastructure or Kubernetes-based gateway stacks.
• MQTT 5.0 support: Full MQTT 5.0 support was added in Mosquitto 1.6. This gives access to message expiry, shared subscriptions, and user properties - features useful for enterprise RFID pipelines - without requiring a paid broker.
• Open source and free: Dual-licensed under the Eclipse Public License and the Eclipse Distribution License. There is no per-connection fee, no licence server, and no vendor lock-in. Source is on GitHub and contributions are accepted.

Limitations

• Single-threaded limits throughput: Because Mosquitto uses a single event loop, it cannot distribute message routing work across multiple CPU cores. Benchmarks typically show throughput plateauing in the range of tens of thousands of messages per second on modern hardware. For high-density RFID deployments with hundreds of readers all publishing at high read rates, this ceiling may be reached. Alternatives such as EMQX or HiveMQ scale horizontally.
• No clustering: Mosquitto has no built-in clustering or high-availability mode. Running two Mosquitto instances requires bridging them, which is an active-active topology with its own complexity and does not provide transparent failover. For HA requirements, a managed cloud broker or a clusterable broker like HiveMQ is a better fit.
• No web UI: Mosquitto ships with no graphical interface. Administration is entirely via config files and command-line tools. Monitoring requires external tooling - either a third-party dashboard that scrapes the $SYS topic tree, or integration with Prometheus via a plugin.
• Limited built-in monitoring: Mosquitto publishes internal statistics to the $SYS/broker/ topic hierarchy (connected clients, message rates, uptime, etc.), but this is the extent of native observability. There is no built-in alerting, no tracing, and no per-client message rate visibility without external tooling.
• Plugin interface is C-only: The authentication and authorisation plugin interface requires writing C code. This is a barrier for teams that want custom auth logic without embedding it in a separate service accessible via the dynamic security plugin.
• No message replay or audit log: Mosquitto does not retain a history of messages beyond the single retained message per topic. There is no built-in replay capability. RFID deployments that need full audit trails must record messages externally - typically by subscribing a logging service that writes to a time-series database or object store.

Mosquitto vs HiveMQ vs AWS IoT Core

Common RFID deployments

• Edge brokers on reader gateways: A Linux-based reader gateway (or a co-located mini-PC) runs Mosquitto alongside LLRP or RAIN RFID middleware. The middleware translates raw reader output into MQTT messages published to the local broker. Other services on the LAN - inventory middleware, a local database writer, an alert engine - subscribe locally. This keeps all RFID traffic on-site and eliminates cloud latency from the critical path for real-time use cases such as dock-door reads triggering WMS updates.
• Store-level MQTT hubs: In retail RFID deployments, each store runs a Mosquitto instance as a site-level hub. All readers in the store publish to this broker. A bridge connection forwards aggregated, filtered events to a regional or central cloud broker. The local hub buffers events during WAN outages and replays them in order when the connection is restored. Store staff can also subscribe to the local broker for in-store tools (cycle count apps, loss prevention dashboards) without cloud round-trips.
• Development and test environments: RFID application teams use Mosquitto in Docker to create isolated test environments. A reader simulator publishes synthetic tag read streams to a local Mosquitto container. Application code under test subscribes and processes events exactly as it would in production, with no dependency on physical readers or production infrastructure. The mosquitto_pub CLI tool is commonly used to inject specific test scenarios - a particular EPC sequence, a burst of reads, or an LWT simulation.
• Warehouse bridging topology: Large warehouse deployments with multiple buildings or zones run a Mosquitto instance per zone, each collecting reads from local readers. A central Mosquitto instance (or a more capable broker) aggregates all zone brokers via bridge connections. This hierarchical topology distributes load, limits blast radius of a broker failure to a single zone, and keeps most MQTT traffic on the local network segment.

Related