Formatos de mensajes y payloads MeshCore
Explicacion practica de como se disenan los mensajes MeshCore para comunicacion de texto confiable sobre LoRa, sin suposiciones incorrectas de otros protocolos.
Como se estructuran los mensajes MeshCore
MeshCore esta disenado para comunicacion de texto liviana sobre LoRa con poco overhead. Los mensajes deben ser compactos porque el airtime LoRa es limitado y afecta directamente alcance, latencia y fiabilidad.
Esta pagina describe comportamiento MeshCore documentado: los clientes no repiten, el forwarding lo hacen repetidores, flood puede usarse para la primera route discovery, y el trafico siguiente puede usar una ruta de repetidores aprendida.
Importante: no copiar nombres de campos ni esquemas de mensajes de otros proyectos mesh. Mantener la documentacion al nivel de comportamiento del protocolo y de propiedades verificadas de MeshCore.
Esquema y estructura interna del mensaje
MeshCore usa representaciones internas compactas para trafico LoRa. La documentacion publica no define un esquema externo estable para tratar como API fija.
Mensaje MeshCore (conceptual): - contexto de origen/destino - payload compacta - contexto de forwarding via comportamiento de repetidores - contexto de integridad y entrega
Para contenido tecnico web, conviene una descripcion conceptual del protocolo en lugar de esquemas de campos no oficiales. Asi evitas implementaciones incorrectas y confusion con otros protocolos.
Formas de mensaje importantes en MeshCore
Mensaje directo (node-to-node)
Mensaje dirigido a un node especifico para comunicacion privada o uno-a-uno.
Mensaje de room
Mensaje a una room (canal de chat) para que varios participantes reciban el mismo contenido.
Discovery forwarding
Si todavia no se conoce una ruta, el routing puede iniciar con flood via repetidores para establecer alcance.
Path learning tras la entrega
Despues de una entrega correcta, se puede aprender informacion de ruta para reenviar el trafico siguiente de forma mas dirigida.
Comportamiento de repetidor
El forwarding ocurre a nivel repetidor; los clientes no forman una capa general de repeticion.
Contenido cifrado
MeshCore soporta cifrado de mensajes. Documentarlo a nivel high-level sin detalles no verificados de implementacion de claves/canales.
Payload y contexto de transporte
Contexto de cabecera y transporte
En MeshCore, esta parte se centra en:
- <strong>Payloads compactas:</strong> mensajes pequenos para reducir airtime LoRa.
- <strong>Contexto de forwarding:</strong> los repetidores gestionan el forwarding; los clientes no repiten.
- <strong>Hops/flood:</strong> el protocolo tiene un limite interno (64); el comportamiento practico se ajusta a nivel repetidor (ej. flood.max).
- <strong>Sin esquema publico fijo de campos:</strong> no publicar campos no oficiales como especificacion rigida.
Tamano de payload en practica
No existe un tamano universal unico de paquete valido siempre para MeshCore. El payload efectivo depende de ajustes LoRa (SF, ancho de banda, coding rate), configuracion regional y comportamiento de firmware.
Guia tecnica
| Parametro | Valor | Descripcion |
|---|---|---|
| Uso principal | Comunicacion de texto compacta | Disenado para intercambio de mensajes fiable a bajas tasas de datos. |
| Modelo de forwarding | Basado en repetidores | Los clientes no repiten; el forwarding lo hacen repetidores/room servers con repeat habilitado. |
| Formacion de rutas | Flood discovery + path learning | La alcanzabilidad inicial puede usar flood y luego el forwarding seguir rutas aprendidas de repetidores. |
| Rooms | Soportado | MeshCore soporta comunicacion en room ademas de mensajes directos node-to-node. |
| Contexto de hops | Limite interno 64 | El comportamiento practico queda limitado por ajustes de repetidor (ej. flood.max). |
| Cifrado | Soportado | Describir a nivel general; evitar afirmaciones no verificadas sobre modelo exacto de claves/canales. |
Por que este enfoque es correcto
Fiel al protocolo
Evita mezclar comportamiento de MeshCore con detalles de otros protocolos mesh.
Menos enganoso
Evita afirmaciones rigidas sobre campos de paquete o limites no definidos oficialmente para MeshCore.
Mas facil de mantener
La documentacion a nivel conceptual se mantiene valida cuando evoluciona el firmware.
Realista para LoRa
Aclara que payload efectivo y comportamiento dependen de ajustes de radio y topologia.
Texto de seguridad mas limpio
Menciona el cifrado correctamente sin detalles no soportados de implementacion.
Modelo de desarrollo mas claro
El lector mantiene el modelo correcto: rooms, repetidores, discovery y learned-path forwarding.
Preguntas frecuentes
MeshCore usa los mismos esquemas de mensajes que otros proyectos LoRa mesh conocidos?
No. No copies esquemas externos 1:1. Describe MeshCore con comportamiento oficialmente documentado.
Todos los nodes repiten mensajes?
No. Los clientes no repiten. El forwarding lo gestionan repetidores (y room servers con repeat habilitado).
Como se maneja la formacion de rutas?
Si no se conoce ruta, se puede usar flood discovery. Tras entrega exitosa, se puede aprender la ruta para forwarding posterior mas dirigido.
MeshCore soporta rooms y mensajes directos?
Si. MeshCore soporta comunicacion en room y mensajeria directa node-to-node.
Cual es el tamano maximo de paquete?
No publiques un valor universal fijo. El tamano efectivo depende de ajustes LoRa, region y comportamiento de firmware.
Los mensajes estan cifrados?
MeshCore soporta cifrado. Mantener la documentacion publica en nivel high-level, sin afirmaciones no verificadas sobre detalles de claves/canales.
Usa documentacion MeshCore correcta
Usa un marco limpio: mensajes compactos, forwarding por repetidores, discovery + rutas aprendidas y restricciones LoRa realistas.