NetbaIoT
Device events in,
business sinks out.
NetbaIoT is an IoT gateway. Devices publish over HTTP, MQTT 3.1.1, TCP, or UDP. The gateway authenticates, decodes, and forwards DeviceEvent values to your webhook or TCP sink. It does not store business data.
Gateway characteristics
- No PostgreSQL or other database in the runtime
- HTTP 202 and MQTT QoS1 mean EventAccepted, not business persistence
- Commands require a live MQTT or TCP session
- Planned shutdown can spool required work; a crash can lose in-memory events
Implemented
- Database-free gateway: HTTP, embedded MQTT 3.1.1, framed TCP, and authenticated UDP
- EventAccepted after auth, codec validation, routing, and atomic required-sink admission
- Confirmed webhook and framed TCP/RPC business sinks; best-effort sinks may drop
- Live-session commands only; offline devices return DeviceOffline and are not queued
- Official Rust business client with explicit event ACK after application processing
- Optional device SDK over standard MQTT/HTTP; standard MQTT clients remain first-class
- Planned shutdown drain into a bounded local restart spool; at-least-once replay
- Separate device and management HTTP listeners, revisioned control snapshots, and CLI
Out of scope
- Crash-durable or exactly-once delivery; SIGKILL can lose the in-memory accepted window
- Offline command storage, durable outbox, or runtime message history
- MQTT 5, MQTT-SN, WebSockets, shared subscriptions, bridge mode, and $SYS
- A required PostgreSQL or other database; business systems own durable data
- Automatic client retry of commands; DeviceOffline is a typed terminal result
- Offline RAM publish queues in the device SDK; disconnected publish is rejected
Device, business, and operator paths.
Devices may use standard MQTT 3.1.1 or device HTTP. Business systems consume confirmed events through netbaiot-client. Operators use the management listener and the netbaiot CLI.
EventAccepted is not business persistence.
HTTP 202 and MQTT QoS1 PUBACK mean the event crossed the bounded EventAccepted boundary: authentication, codec validation, routing, and atomic reservation of every confirmed-required sink. They do not mean a business database stored the event. Consumers must deduplicate by stable event_id.
Commands are live-session only.
A command is admitted only into a currently connected local MQTT or TCP session queue. An offline device returns typed DeviceOffline. NetbaIoT does not store offline commands.
Planned restart, not crash durability.
Planned shutdown drains required work into a bounded local restart spool with fsync and atomic rename. That is graceful-restart-safe at-least-once delivery. SIGKILL, process crash, or power failure can lose the in-memory accepted window.
Questions
Does NetbaIoT need a database?
No. The runtime is database-free. Business systems own durable business data. NetbaIoT's only persistent mechanism is a bounded local restart spool used during planned graceful shutdown.
What does HTTP 202 or MQTT QoS1 PUBACK mean?
They mean EventAccepted: authentication, codec validation, routing, and atomic reservation of every confirmed-required sink. They do not mean a business database stored the event. Consumers must deduplicate by event_id.
Are commands stored for offline devices?
No. A command is admitted only into a currently connected local MQTT or TCP session. An offline device returns typed DeviceOffline.