Las limitaciones de un broker MQTT público son fáciles de ignorar durante la primera hora entusiasta de un proyecto y dolorosas de descubrir delante de un cliente. Este artículo explica las cuatro restricciones principales de los brokers públicos de pruebas, usando broker.connectmq.com como ejemplo concreto, muestra cómo diseñar tus pruebas para trabajar dentro de ellas y enumera las señales claras de que ha llegado el momento de pasar a un broker privado.
Por qué los brokers públicos tienen límites
Un broker público es un servicio compartido y anónimo. Cualquiera en Internet puede conectarse, publicar y suscribirse sin cuenta. Esa apertura es justo lo que lo hace útil para tutoriales y pruebas rápidas, y justo la razón por la que necesita límites: sin ellos, un único script descontrolado podría inundar el broker y estropearlo para todos los demás.
Los límites no son un defecto. Son lo que mantiene utilizable un servicio comunitario gratuito. ConnectMQ ofrece broker.connectmq.com exactamente con este propósito: un lugar sin configuración para aprender MQTT, probar una librería o enseñar una demo, junto a brokers privados para cargas de trabajo reales. El artículo sobre el servidor MQTT público gratuito describe cómo sacar partido a broker.connectmq.com; este artículo se centra en lo que no puede hacer.
Limitación 1: sin privacidad
En un broker público, cualquier cliente puede leer cualquier topic. Un suscriptor a # recibe todo lo que se publica, dentro de las protecciones propias del broker. Los nombres de los topics no son secretos, y los prefijos rebuscados solo reducen las colisiones accidentales.
Lo que esto significa en la práctica:
- Nunca publiques datos personales, rastros de ubicación, capturas de cámara ni nada que identifique a una persona o una vivienda.
- Nunca publiques credenciales, claves de API ni contraseñas de Wi-Fi, ni siquiera "temporalmente".
- Nunca controles equipos reales desde un topic público. Cualquiera puede publicar en tu topic de comandos, no solo leerlo.
- Da por hecho que alguien, en algún lugar, registra los payloads.
Usa un prefijo aleatorio como connectmq/demo/9b2e7/ para que tu tráfico de pruebas no choque con el de otros. Es una cortesía y una comodidad, no una medida de seguridad.
Limitación 2: sin garantías de servicio
Los brokers públicos se ofrecen como servicio de mejor esfuerzo. No hay SLA, ni disponibilidad garantizada, ni compromiso de soporte. El broker puede reiniciarse por mantenimiento, los límites pueden cambiar y las sesiones no sobreviven a la ventana de caducidad. En broker.connectmq.com, la caducidad de sesión está limitada a 30 minutos, de modo que un dispositivo que pasa más tiempo desconectado empieza de cero.
Para una demo o un taller, no hay problema. Para un producto, un piloto o cualquier cosa de la que dependa un cliente, sí lo hay.
Prepárate para el silencio
Como no hay garantías, escribe tus clientes de prueba para que soporten interrupciones. Activa la reconexión automática, vuelve a suscribirte en el callback de conexión en lugar de hacerlo una sola vez al arrancar y no trates un mensaje perdido como un error de tu propio código hasta haber descartado un reinicio del broker. Estos hábitos son buena práctica con cualquier broker y facilitan el paso posterior a producción.
Limitación 3: un espacio de topics compartido
Todos los usuarios públicos comparten un mismo árbol de topics. Las consecuencias son:
- Colisiones. Nombres populares como
test,sensor/tempohome/livingroomlos usa mucha gente. Recibirás sus mensajes y ellos recibirán los tuyos. - Sorpresas con los retained messages. El retained message de otra persona en un topic genérico aparecerá en cuanto te suscribas.
- Ruido de los wildcards. Suscribirte de forma amplia te devuelve tráfico que nunca pediste y consume tu margen de tasa.
Usa siempre un prefijo único como espacio de nombres para los topics y suscríbete de forma acotada.
Limitación 4: límites de tasa, tamaño y suscripciones
El broker público limita los recursos por cliente para que todos tengan un acceso justo. En broker.connectmq.com los límites son:
| Límite | Valor en el broker público | Por qué existe |
|---|---|---|
| Tamaño de mensaje | 64 KB por mensaje | Evita que los payloads grandes acaparen el ancho de banda |
| Tasa de publicación | 10 mensajes por segundo por cliente | Impide que los scripts inunden el broker |
| Suscripciones | 10 por cliente | Limita el coste de distribución por cliente |
| Profundidad de topic | 8 niveles de topic | Mantiene eficiente la coincidencia de topics |
| QoS | 0, 1 y 2 | Comportamiento completo del protocolo para aprender |
| Caducidad de sesión | Hasta 30 minutos | Libera recursos de sesiones abandonadas |
| Autenticación | Anónima, cualquier client ID único no vacío | Cero configuración para quien aprende |
Superar un límite puede provocar el rechazo de operaciones o una desconexión. Si te conectas con MQTT 5, registra los reason codes que recibe tu cliente; te dicen mucho más que un genérico "conexión perdida".
Diseñar pruebas que respeten los límites
Aquí tienes un publicador en Python (paho-mqtt 2.x) que se mantiene holgadamente dentro de los límites públicos: client ID único, prefijo único, topics poco profundos, una tasa acotada y payloads compactos.
import json
import random
import time
import uuid
import paho.mqtt.client as mqtt
RUN_ID = uuid.uuid4().hex[:6]
PREFIX = f"connectmq/demo/{RUN_ID}" # 3 levels, leaves room below
MAX_RATE = 5 # messages per second, under the 10/s cap
INTERVAL = 1.0 / MAX_RATE
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code, "prefix:", PREFIX)
def on_disconnect(client, userdata, flags, reason_code, properties):
print("Disconnected:", reason_code)
client = mqtt.Client(
mqtt.CallbackAPIVersion.VERSION2,
client_id=f"limits-demo-{RUN_ID}",
protocol=mqtt.MQTTv5,
)
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
try:
for i in range(50):
payload = json.dumps({"i": i, "t": round(20 + random.random() * 2, 2)})
assert len(payload.encode()) < 64 * 1024
client.publish(f"{PREFIX}/sensor/temp", payload, qos=1)
time.sleep(INTERVAL)
finally:
client.loop_stop()
client.disconnect()
Obsérvalo desde un segundo terminal, suscribiéndote solo a tu propio prefijo:
mosquitto_sub -h broker.connectmq.com -p 1883 -i watch-RUNID -t "connectmq/demo/RUNID/#" -v
Sustituye RUNID por el prefijo que muestra el script.
Errores habituales
- Client ID vacío. El broker público exige un client ID no vacío. Genera uno único en cada ejecución.
- Dos scripts con el mismo client ID. Cada conexión expulsa a la otra, lo que provoca un bucle de reconexiones.
- Bucles de publicación sin pausa. Un bucle
while Truesin sleep supera el límite de tasa en menos de un segundo. - Árboles de topics profundos.
connectmq/demo/abc/site/area/line/cell/machine/sensortiene 9 niveles y supera el límite de 8. Aplana los topics de prueba. - JSON grandes o imágenes. Todo lo que se acerque a 64 KB debe ir a un broker privado, y las imágenes rara vez tienen sitio en MQTT.
Señales de que ha llegado el momento de un broker privado
Abandona el broker público en cuanto notes cualquiera de estas señales:
- Los datos avergonzarían o perjudicarían a alguien si los leyera un desconocido.
- Un dispositivo ejecuta los comandos que recibe.
- Un cliente, un compañero o un profesor depende de que el sistema funcione mañana.
- Necesitas más de 10 suscripciones por cliente, mensajes más grandes o jerarquías de topics más profundas.
- Quieres ver quién está conectado y mantener credenciales por dispositivo.
La comparativa entre broker MQTT público vs privado recorre el cambio, y el artículo sobre pasar del prototipo a producción cubre el resto del camino.
Qué cambia con un plan privado
Un broker privado de ConnectMQ mantiene el mismo protocolo y el mismo código cliente, pero cambia las reglas:
- Autenticación con usuario, contraseña y client ID generados, con el client ID vinculado a esas credenciales.
- Aislamiento respecto a otros tenants, de modo que tu espacio de topics es solo tuyo.
- TLS en el 8883 y Secure WebSocket en el 8084 con un certificado de Let's Encrypt.
- Límites según el plan: el plan Serverless gratuito permite hasta 25 conexiones, QoS hasta 1 y mensajes de 256 KB; el plan Serverless de pago lo amplía a hasta 1.000 conexiones, QoS 2, mensajes de 1 MB y suscripciones compartidas.
- Herramientas del portal como un cliente en el navegador, un explorador de topics en vivo, un dashboard y alertas por umbral.
Pasa gratis a un broker privado de ConnectMQ
Cuando el servidor público haya cumplido su función, crea tu broker privado gratuito en el plan Serverless, sin tarjeta de crédito, y apunta el mismo script al puerto 8883 con tus nuevas credenciales. Lee la guía de brokers MQTT en la nube para planificar los siguientes pasos, descubre por qué un broker MQTT gestionado ahorra esfuerzo de operación o visita connectmq.com para comparar planes.
Preguntas frecuentes
¿Es seguro usar un broker MQTT público?
Es seguro para aprender y hacer demos con datos inofensivos. No lo es para datos personales, credenciales ni para controlar equipos reales, porque cualquiera puede leer y publicar en cualquier topic.
¿Qué ocurre si supero el límite de tasa del broker público?
Las operaciones pueden rechazarse o el cliente puede desconectarse. Publica por debajo de 10 mensajes por segundo por cliente y revisa los reason codes de MQTT 5 al depurar.
¿Por qué recibo mensajes que no he publicado?
Otros usuarios publican en los mismos nombres de topic. Usa un prefijo único como connectmq/demo/<random-id>/ y suscríbete solo a ese prefijo.
¿Conserva el broker público mi sesión si mi dispositivo se desconecta?
Solo dentro de la ventana de caducidad de sesión, limitada a 30 minutos en broker.connectmq.com. Después, el dispositivo empieza una sesión nueva.
