Client types
TBMQ classifies every connecting MQTT client as either a DEVICE or an APPLICATION client. The type is not a label for reporting — it selects how the broker stores and delivers that client’s messages, above all while the client is offline. Getting it right per client is one of the decisions a deployment is hardest to revisit later.
The split mirrors the two roles that dominate real IoT systems. Most clients either produce data at the edge (sensors, actuators, gateways) or consume it in bulk (analytics engines, rule processors, integration services), and the two have very different persistence and throughput profiles. Rather than applying one storage strategy to everything, TBMQ optimizes a separate path for each.
When to use what
Section titled “When to use what”| DEVICE | APPLICATION | |
|---|---|---|
| Role | Publishes frequently; subscribes to a few low-traffic topics | Subscribes to many topics, or to high-rate streams |
| Typical clients | Sensors, actuators, controllers, IoT gateways | Analytics engines, rule processors, backend services |
| Session type | Persistent or non-persistent | Persistent |
| Offline messages | Queued in Redis, bounded by a per-client limit and a TTL | Retained in a durable, replayable Kafka log of its own |
| Scales with | More broker nodes, more Redis capacity | More broker nodes, more Kafka capacity |
| Assigned by default | Yes | No — must come from the client’s identity |
Choose DEVICE for anything that lives at the edge, and APPLICATION for a backend consumer that must not miss a message and reads far more traffic than any single device produces. An APPLICATION client is a heavier object for the broker — it gets storage and a consumer of its own — so it is the wrong choice for a fleet of thousands of sensors, and the number of them a cluster accepts can be capped deliberately.
How TBMQ assigns the client type
Section titled “How TBMQ assigns the client type”The type is resolved during the CONNECT handshake, from the client’s authenticated identity — never from the CONNECT
packet, so a client cannot select its own type:
- With all MQTT authentication providers disabled, authentication is bypassed and every client is assigned DEVICE.
- With at least one provider enabled, the type comes from whatever authenticated the client: the client type recorded on the matched credentials for Basic, X.509 and SCRAM, or the authentication result for JWT and HTTP, which can return a different type per connection.
Retyping a client takes effect on its next connection, and a client that stops being an APPLICATION client has its dedicated storage reclaimed.
See MQTT client type for the resolution rules and the persistence parameters of each type, the security overview for the providers that supply it, and the architecture overview for both delivery paths end to end.
Was this helpful?