Protocolo de comunicación

Este documento especifica por completo el formato de comunicación entre agent, exchange y cli. Las definiciones están en crates/proto y los tres componentes comparten el mismo código: cada campo se añade o elimina en un único lugar y las discrepancias aparecen durante la compilación, antes de una sesión en producción.

Está dirigido a operadores que inspeccionan paquetes para diagnosticar problemas y a desarrolladores que modifican el protocolo o escriben clientes de terceros.

Índice

• Descripción general
• Transporte y endpoints
• Versión del protocolo
• Mensajes de control
  • DeviceUp (agent → exchange)
  • DeviceDown (exchange → agent)
  • OperatorUp (cli → exchange)
  • OperatorDown (exchange → cli)
  • Estructuras de datos compartidas
• Tramas de datos binarias
• Traducción entre dos espacios de identificadores de sesión
• Secuencia del handshake
• Tratamiento de errores y clasificación de fallos
• Mantenimiento de conexión y tiempos de espera
• Contrapresión
• Control de pantalla de Android
• Sesiones selladas de extremo a extremo

Descripción general

El protocolo tiene dos capas que comparten una conexión WebSocket:

La separación evita el crecimiento aproximado del 33 % que supone introducir datos de flujo en JSON mediante base64. Los PTY generan pequeños paquetes frecuentes al reflejar cada pulsación, por lo que ese coste aumenta directamente la latencia interactiva. Los mensajes de control son poco frecuentes y se benefician más de la legibilidad de JSON: permite entender capturas de paquetes.

Por convención, una trama WebSocket binaria contiene exactamente una trama de datos: tanto los bytes sobrantes como los ausentes se consideran errores.

Transporte y endpoints

Las dos rutas usan credenciales distintas y no intercambiables. Un token de dispositivo no sirve para el endpoint de operadores, ni viceversa.

Las credenciales de operador van en una cabecera y no en la consulta de la URL, porque esta puede aparecer en registros del proxy inverso, historial del navegador y Referer. El token del dispositivo va en la primera trama porque algunos clientes integrados dificultan personalizar las cabeceras del handshake WebSocket. Además, este mecanismo permite comunicar tanto una incompatibilidad de versión como un token incorrecto mediante la misma respuesta.

En producción se debe usar wss://: ambas credenciales aparecen en texto sin cifrar durante el handshake.

Versión del protocolo

pub const PROTOCOL_VERSION: u16 = 1;

Las versiones se comparan en ambos sentidos durante el handshake. Una discrepancia provoca un rechazo inmediato con un mensaje claro, evitando que una incompatibilidad se manifieste después como un fallo inexplicable al analizar algún mensaje, difícil de diagnosticar.

• Dispositivos: agent incluye su versión en register; si no coincide, el servidor responde con register_ack y ok: false, explica ambas versiones en error y cierra la conexión.
• Operadores: el servidor envía welcome al conectar. Si la versión no coincide, CLI devuelve un error e indica que debe actualizarse a una versión compatible con server_version.

Todo type de mensaje desconocido se rechaza; nunca se interpreta silenciosamente como un tipo conocido.

Mensajes de control

Todos los mensajes de control son objetos JSON etiquetados con type (enumeraciones con etiquetado interno de serde). Las etiquetas y los nombres de campo usan snake_case. session_id se serializa de forma transparente como un número sin envoltura.

DeviceUp (agent → exchange)

Un segundo register en una conexión ya registrada se considera uso incorrecto del protocolo y genera una advertencia en el servidor.

Ejemplo:

{"type":"register","protocol_version":1,"device_id":"lab-router","token":"a1b2….c2Vj…","info":{"hostname":"OpenWrt","model":"ath79/generic","openwrt_version":"OpenWrt 23.05.5","kernel":"5.15.137","arch":"mips","agent_version":"0.1.0"}}
{"type":"exec_exit","session_id":31,"code":0,"timed_out":false}

DeviceDown (exchange → agent)

OperatorUp (cli → exchange)

La autenticación se completa durante el handshake WebSocket, por lo que no hay mensajes de inicio de sesión.

El session_id de los cuatro mensajes open_* lo asigna el propio CLI (véase Traducción entre dos espacios de identificadores de sesión), de modo que puede enviar tramas posteriores inmediatamente, sin esperar confirmación del identificador.

OperatorDown (exchange → cli)

Estructuras de datos compartidas

ExecHoldInfo: job_id, kind (exec / download / upload / file), age_secs, session_id?, command_preview, status, timeout_secs, started_at_unix_ms, exit_code?, timed_out. Por compatibilidad, kind ausente equivale a exec y age_secs a 0; la lista calcula la antigüedad con el reloj actual. El resumen del comando o ruta tiene un máximo aproximado de 120 caracteres. Los trabajos que no son exec solo admiten kill, no tail/cat/attach.

DeviceSessionInfo: session_id: u32 (identificador del dispositivo), operator_session_id: u32, kind: string, hold: bool, age_secs: u64, deadline_unix_ms: u64. Exchange responde directamente a la lista de sesiones y cancelación forzada sin abrir sesiones nuevas en el dispositivo; las cuentas de solo lectura reciben forbidden.

DeviceInfo

Información estática enviada una vez en register y almacenada en devices.info. Todos los campos salvo agent_version son opcionales: fuera de OpenWrt (equipos de desarrollo o contenedores), la mayoría de fuentes no existen y agent debe registrarse normalmente en lugar de fallar al arrancar. Los campos ausentes se omiten al serializar.

Metrics

Se recopilan en cada ciclo de latidos, solo de fuentes legibles directamente en /proc, sin crear procesos secundarios. Un fallo de lectura individual no invalida el informe: perder una métrica es preferible a perder todo el latido y considerar desconectado al dispositivo.

InterfaceStats: { name: string, rx_bytes: u64, tx_bytes: u64 }

Tramas de datos binarias

 0        1                    5                    9
 +--------+--------------------+--------------------+
 |  kind  |     session_id     |    payload_len     |  payload (payload_len 字节)
 |   u8   |    u32 (大端)      |    u32 (大端)      |
 +--------+--------------------+--------------------+
 └──────────── 9 字节定长头 ────────────┘

Tipos de flujo

Si agent recibe ExecStdout / ExecStderr hacia el dispositivo, registra una advertencia y lo descarta: indica un error de implementación del otro extremo.

Notas de diseño

payload_len es redundante con la longitud de WebSocket. Se mantiene por dos motivos: detectar truncamientos al decodificar (declarar 11 bytes y enviar solo 5 debe rechazarse, no aceptarse silenciosamente como paquete corto), y permitir una futura migración a TCP sin modificar el formato.

El límite de 1 MiB no está pensado para el tráfico normal: PTY y salida de comandos se transmiten incrementalmente y no alcanzan ese tamaño. Impide que una cabecera que declare 2 GiB agote la memoria del servidor.

Una carga vacía es válida: los PTY pueden producir lecturas de cero bytes. La trama contiene entonces solo la cabecera de 9 bytes.

La carga puede contener cualquier byte, incluidas secuencias no UTF-8, y debe conservarse sin cambios.

Errores de decodificación

Un fallo de decodificación solo afecta a esa trama: exchange registra una advertencia y la descarta sin cerrar la conexión.

Traducción entre dos espacios de identificadores de sesión

Esta es la parte del protocolo que más fácilmente se malinterpreta.

En una frase

session_id lo asigna quien inicia la sesión y solo es único dentro de su propia conexión. Operadores y dispositivos tienen espacios independientes y exchange los traduce. Una misma sesión lógica tiene dos identificadores distintos.

  remote-cli                    exchange                      remote-agent
                                                        （设备 lab-router）

  ┌────────────┐        ┌────────────────────┐            ┌────────────┐
  │ 运维编号   │        │      路由表        │            │ 设备编号   │
  │  空间      │        │                    │            │  空间      │
  │            │        │  lab-router:       │            │            │
  │  session 7 │───────▶│    31 → (op-A, 7)  │───────────▶│ session 31 │
  │            │◀───────│                    │◀───────────│            │
  └────────────┘        │  op-A:             │            └────────────┘
                        │    7 → (lab-router,│
   由 CLI 自己的        │         31)        │             由 exchange
   SessionIdGenerator   └────────────────────┘             的 DeviceHandle
   分配（1,2,3…）                                          分配（1,2,3…）

Motivos del diseño

Evitar un viaje de ida y vuelta. Si el servidor asignara todos los identificadores, CLI tendría que esperar la respuesta «tu sesión es 31» tras abrir PTY antes de enviar entrada de teclado. Al asignarlo CLI, puede enviar tramas inmediatamente después de open_pty.

Evitar colisiones entre operadores. Dos operadores pueden usar simultáneamente el identificador local 1 sobre el mismo dispositivo. Este debe distinguirlos para que la salida de uno no llegue al otro. exchange asigna identificadores por conexión de dispositivo y traduce ambos session 1 a 31 y 32 en el dispositivo.

Independizar los identificadores del dispositivo del comportamiento del operador. exchange los controla por completo; ningún operador puede elegirlos ni adivinarlos.

Dos tablas

exchange mantiene una tabla por conexión y actualiza ambas siempre en pareja:

El índice inverso permite limpiar: cuando un operador se desconecta, hay que localizar y terminar las sesiones que dejó en todos los dispositivos, evitando procesos y PTY cuya salida nadie recibe.

Dónde se traduce

La traducción es la única modificación de una trama: exchange no analiza, almacena ni modifica ningún byte de carga. DataFrame::with_session_id sustituye el identificador in situ sin reasignar la carga.

Reglas de asignación

Ambos asignadores comienzan en 1 e incrementan saltándose el 0, reservado como centinela sin sesión, por ejemplo en errores de conexión.

• CLI (SessionIdGenerator): al desbordarse vuelve al inicio y salta el 0. Agotar cuatro mil millones de sesiones en una conexión es poco realista, pero volver al inicio encaja mejor con procesos persistentes que provocar panic.
• Dispositivo (DeviceHandle::open_session): si al volver al inicio encuentra una sesión antigua activa, sigue buscando un identificador libre.

exchange rechaza el 0 y la reutilización de identificadores activos por operadores. La validez de conexión del dispositivo, el límite de concurrencia y el registro en ambos índices se comprueban en la misma sección crítica para impedir superar el límite al abrir varias conexiones de operador a la vez.

Comportamiento si no existe una ruta

Descarte silencioso, sin error. Es normal que haya una carrera cuando una sesión acaba de cerrarse y el otro extremo aún envía datos finales. La regla vale en ambos sentidos:

• Dispositivo responde a una sesión inexistente → registro debug; quizá el operador se desconectó antes.
• Operador envía datos de una sesión sin propietario → registro trace y descarte.

Rutas de limpieza de sesiones

El índice inverso se liga a una conexión concreta del dispositivo y no se redirige por ID a la nueva conexión tras reconectar. Cada conexión de operador, incluso de la misma cuenta, tiene su propio índice: desconectar una no cancela sesiones de otra.

Confirmaciones de cancelación explícita: exec devuelve exec_exit (code: null, timed_out: false); PTY devuelve pty_closed (code: null); ubus devuelve session_failed (reason: device_error). Confirman que exchange cerró la sesión, sin demostrar que el proceso remoto terminara; se descartan los datos y mensajes de salida posteriores del dispositivo.

Al alcanzar el límite de concurrencia, Exchange recupera primero, bajo el mismo bloqueo, rutas sin operador o fuera de plazo y vuelve a comprobar el límite. El plazo exec es el límite real enviado más 15 segundos de margen; el de archivos, 3600 segundos más 15; los demás, 24 horas. Un exec hold dentro de plazo sobrevive a la marcha del operador. La recuperación y kill_device_session envían cancelación al dispositivo y eliminan ambos índices inmediatamente sin esperar respuesta; los operadores disponibles reciben exec_exit con timed_out:true para exec o session_failed con device_error y session reclaimed para otros tipos. La auditoría se completa asíncronamente en la medida de lo posible.

Reconexión de dispositivos y epoch

Cada conexión de dispositivo recibe un epoch (UUID) aleatorio al registrarse. Al reconectar el mismo dispositivo, la nueva conexión sustituye a la anterior: no se rechaza, porque no se distingue con fiabilidad una conexión duplicada de una antigua muerta que el servidor aún no detectó (conexión semiabierta). Rechazarla impediría reconectar hasta que expirara la antigua.

La limpieza antigua puede ejecutarse después del registro nuevo. Al desregistrar debe comprobarse epoch y eliminar solo si el epoch actual de la tabla coincide con el propio. Sin esta comprobación, la limpieza antigua marcaría inmediatamente como desconectado al dispositivo recién conectado.

Secuencia del handshake

Dispositivo

  remote-agent                                        exchange
      │                                                 │
      │  ①  WebSocket 握手（wss://host/ws/device）      │
      │────────────────────────────────────────────────▶│
      │◀────────────────────────────────────────────────│
      │            101 Switching Protocols              │
      │                                                 │
      │                                          ┌──────┴──────┐
      │                                          │ 启动 15 秒  │
      │                                          │ 注册计时器  │
      │                                          └──────┬──────┘
      │  ②  {"type":"register","protocol_version":1,    │
      │      "device_id":"…","token":"…","info":{…}}    │
      │────────────────────────────────────────────────▶│
      │                                                 │
      │                              ┌──────────────────┴──────────────────┐
      │                              │ a. 比对 protocol_version            │
      │                              │ b. split_token → 前缀查 devices 表  │
      │                              │ c. 校验 enabled                     │
      │                              │ d. argon2 verify（前缀不符也照做，  │
      │                              │    避免用耗时区分前缀是否存在）     │
      │                              └──────────────────┬──────────────────┘
      │                                                 │
      │  ③  {"type":"register_ack","ok":true,           │
      │      "error":null,"heartbeat_interval_secs":30} │
      │◀────────────────────────────────────────────────│
      │                                                 │
      │                                          ┌──────┴──────┐
      │                                          │ 登记连接表  │
      │                                          │ 顶替旧连接  │
      │                                          │ 回写 info 与│
      │                                          │ last_seen_at│
      │                                          └──────┬──────┘
      │                                                 │
      │  ④  退避曲线复位，写状态文件 state=connected     │
      │                                                 │
      │══════════════ 转发循环 ═══════════════════════════│
      │                                                 │
      │  heartbeat（每 30 秒，携带 Metrics）             │
      │────────────────────────────────────────────────▶│
      │  WebSocket Ping（随每次 heartbeat 发出）         │
      │────────────────────────────────────────────────▶│
      │                                     WebSocket Pong
      │◀────────────────────────────────────────────────│
      │                                     WebSocket Ping（每 30 秒）
      │◀────────────────────────────────────────────────│
      │  Pong（tungstenite 排队，agent 显式 flush）       │
      │────────────────────────────────────────────────▶│

Rutas de fallo:

• Primera trama no textual, JSON inválido o mensaje distinto de register → registra advertencia y cierra directamente, sin ack.
• No se envía register en 15 segundos → cierra la conexión.
• Versiones incompatibles → responde register_ack{ok:false, error:"协议版本不匹配：设备为 X，服务端为 Y"} y cierra.
• Token inválido / dispositivo inexistente / dispositivo desactivado → responde siempre "设备 ID 或令牌无效" y cierra. No distingue causas, para no convertir el inventario en información enumerable.

agent trata estas dos categorías de fallo por separado:

La espera solo se reinicia tras un registro correcto, no al establecer TCP. De lo contrario, conectar y ser rechazado inmediatamente causaría reintentos intensivos cada pocos milisegundos.

La variación aleatoria es necesaria. Tras reiniciar el servidor, cientos o miles de dispositivos detectan la caída a la vez. Si reconectaran con la misma curva determinista, seguirían sincronizados y golpearían por oleadas al servidor recién iniciado, convirtiendo un reinicio en una avalancha persistente.

Operador

  remote-cli                                          exchange
      │                                                 │
      │  ①  WebSocket 握手（wss://host/ws/operator）    │
      │      Authorization: Bearer <prefix>.<secret>    │
      │────────────────────────────────────────────────▶│
      │                                                 │
      │                              ┌──────────────────┴──────────────────┐
      │                              │ 在 upgrade 之前完成鉴权：           │
      │                              │ split_token → 前缀查 operators 表   │
      │                              │ → argon2 verify → 校验 enabled      │
      │                              └──────────────────┬──────────────────┘
      │                                                 │
      │      鉴权失败 → HTTP 401「凭证无效」（不升级）   │
      │◀────────────────────────────────────────────────│
      │                                                 │
      │◀────────────────────────────────────────────────│
      │            101 Switching Protocols              │
      │                                                 │
      │  ②  {"type":"welcome","protocol_version":1,     │
      │      "server_version":"0.1.0"}                  │
      │◀────────────────────────────────────────────────│
      │                                                 │
      │  ③  比对 protocol_version（15 秒超时）          │
      │      不一致 → 报错退出，提示升级 CLI            │
      │                                                 │
      │══════════════ 可以发起会话 ═══════════════════════│
      │                                                 │
      │  {"type":"open_pty","session_id":1,             │
      │   "device_id":"lab-router","rows":40,"cols":120}│
      │────────────────────────────────────────────────▶│
      │                                                 │──▶ 查设备在线
      │                                                 │──▶ 查并发上限
      │                                                 │──▶ 查 readonly 角色
      │                                                 │──▶ 写审计（先于下发）
      │                                                 │──▶ 分配设备侧编号
      │  二进制帧（PtyData, session 1, 键盘输入）        │
      │────────────────────────────────────────────────▶│──▶ 改写为设备侧编号
      │                                                 │
      │  二进制帧（PtyData, session 1, 屏幕输出）        │
      │◀────────────────────────────────────────────────│◀── 改写为运维侧编号

CLI puede enviar las tramas de datos del segundo paso sin esperar ninguna confirmación: esa es la finalidad de que el iniciador asigne el identificador.

Tratamiento de errores y clasificación de fallos

SessionFailure

Aparece en reason de session_failed; sus valores JSON usan snake_case.

is_retryable() excluye deliberadamente forbidden y device_error: reintentar permisos o fallos internos del dispositivo no tiene sentido y solo mantiene CLI ocupado.

CLI añade al message original una indicación práctica. Por ejemplo, device_offline sugiere comprobar el estado con remote-cli device list. device_error es la excepción: el mensaje del dispositivo ya es la explicación más precisa y no conviene diluirlo con texto genérico.

Semántica de fallos por capas

El principio es mantener locales todos los fallos que puedan aislarse, ya que una conexión de dispositivo puede transportar sesiones de varios operadores simultáneamente.

Mantenimiento de conexión y tiempos de espera

El cliente de un shell inactivo sigue respondiendo Pong. agent hace flush explícito de respuestas encoladas automáticamente sin esperar al siguiente latido; la ausencia de teclado no provoca falsas desconexiones (#42). --heartbeat-secs debe ser mayor que 0; los valores inválidos se rechazan al analizar argumentos de inicio.

Contrapresión

exchange mantiene para cada conexión una cola de envío acotada de 512 mensajes.

Una cola llena significa que el otro extremo no consume al ritmo necesario; en PTY suele indicar una red bloqueada o cliente suspendido. Se cierra activamente la conexión: acumular sin límite convertiría un cliente bloqueado en una fuga de memoria de todo el servicio. 512 mensajes dejan margen amplio para PTY interactivo, cuya cola normalmente tiene una longitud de un solo dígito; alcanzar el límite indica casi con certeza que el receptor ya no consume.

Todos los envíos usan try_send no bloqueante. El enrutamiento mantiene bloqueada la tabla de conexiones; cualquier await vincularía la duración del bloqueo al consumo del otro extremo y un cliente lento bloquearía toda la tabla.

Se distinguen dos fallos de entrega:

La señal de cierre no pasa por la cola y puede iniciar la limpieza incluso con la cola llena o escritura bloqueada. La sustitución por reconexión y la rotación de tokens usan el mismo mecanismo.

agent también tiene una cola de salida de capacidad 256. Llenarla significa que la red no transmite y seguir acumulando no tiene sentido: debe desconectar y reconectar. Si se llena la cola de entrada PTY (64), descarta pulsaciones directamente; acumular pequeños datos interactivos no aporta nada.

Control de pantalla de Android

Las definiciones están en crates/proto/src/android.rs y reutilizan rutas de sesión de dos espacios, autenticación, límites de concurrencia y auditoría. request de open_android / android_req es un objeto JSON discriminado por action:

AndroidResult se discrimina por kind; todos los campos son obligatorios:

Los nodos contienen las cadenas class_name, package, view_id, text, description, bounds: [left, top, right, bottom] (coordenadas de pantalla con signo) y los booleanos clickable, editable, focused, password. Hay como máximo 200 nodos y 256 unidades UTF-16 por cadena; truncated solo indica el límite de nodos. Valores y descripciones de contraseñas quedan vacíos y se omite el subárbol de configuración del propio agent.

El lado largo de las capturas mide como máximo 1600 píxeles. width/height son dimensiones de imagen; screen_width/screen_height, las anteriores al escalado. Los gestos usan coordenadas originales. El JSON del puente Java admite 2 MiB, más 1024 bytes para la envoltura WebSocket. No se añade ningún tipo de trama binaria.

{"type":"open_android","session_id":1,"device_id":"phone","request":{"action":"input_text","text":"Hello\nWorld"}}
{"type":"android_req","session_id":31,"request":{"action":"input_text","text":"Hello\nWorld"}}
{"type":"android_resp","session_id":31,"result":{"kind":"ok"}}
{"type":"android_resp","session_id":1,"result":{"kind":"ok"}}

screen_capture_enabled indica una autorización de captura disponible (MediaProjection o accesibilidad en Android 11+); todas las operaciones reales de pantalla siguen requiriendo controls_enabled. Ante permisos insuficientes, ventanas inaccesibles o fallos, agent devuelve session_error, que Exchange convierte en session_failed. Los agent no Android devuelven un error explícito de operación no compatible.

Agent procesa como máximo 4 solicitudes Android simultáneas y codifica solo una captura a la vez. Las operaciones Java esperan hasta 10 segundos (hasta 5 por un fotograma); agent tiene timeout de 15 segundos y CLI de 20. Al cancelar o desconectarse el operador, Exchange envía android_cancel; agent cierra el socket local y APK cancela trabajos en cola aún no ejecutados. Los gestos y modificaciones de texto ya ejecutados no se revierten.

La acción de auditoría es android; detail guarda acción y coordenadas. input_text solo guarda characters (número de caracteres Unicode); los resultados correctos solo registran outcome: "completed". Texto, árbol de interfaz e imágenes no se auditan. Las cuentas readonly tampoco pueden iniciar status, tree ni capturas.

Extensión de sesiones de archivos

Los Agent compatibles declaran la capacidad files. Exchange traduce open_file {session_id, device_id, request} a file_req {session_id, request}; request.action es list, download o upload; los campos se definen en crates/proto/src/files.rs.

El control bidireccional usa JSON: el controlador envía file_input {session_id, input} y el dispositivo responde file_event {session_id, event}. input.kind es chunk {offset, data}, ack {offset} o finish; event.kind es ready {size}, chunk {offset, data}, progress {received}, complete {size} o list {path, entries, truncated}. Los bloques usan Base64 estándar, con máximo de 64 KiB; el emisor espera confirmación antes de continuar.

El primer ready de una descarga requiere ack {offset: 0}; luego cada bloque confirma los bytes acumulados. Una carga comienza con ready; cada progress impulsa el bloque siguiente y finish confirma la operación tras enviar todos. complete y list son mensajes finales; los errores usan session_error / session_failed. close_session envía file_cancel; cancelación y desconexión eliminan la ruta. Los mensajes de archivo solo se reenvían en sesiones de archivo, manteniendo separados los identificadores de operador y dispositivo.

La versión sigue siendo 1; los mensajes nuevos requieren actualizar conjuntamente Exchange y Agent. Las restricciones e interfaces LAN se describen en Transferencia de archivos y conexión directa por LAN.

Extensiones multiplataforma

La versión sigue siendo 1. El info de registro añade los opcionales platform (openwrt / linux / freebsd / netbsd / windows / android / macos), os_version, capabilities (exec / pty / ubus / android_control / files / sensors / net). OpenWrt comunica openwrt_version.

metrics.unavailable del latido es un array opcional de cadenas que enumera métricas uptime, load, memory, cpu, interfaces no recopilables. Su ausencia se interpreta como el formato antiguo; los valores de métricas enumeradas son marcadores de compatibilidad y el cliente debe mostrarlas como ausentes. Windows no ofrece carga media Unix y Android puede restringir fuentes /proc por permisos del sistema.

Los comandos se interpretan con el shell de destino: /bin/sh en Linux/OpenWrt/macOS, PowerShell en Windows y /system/bin/sh en Android. Las tramas y controles PTY son iguales en los tres sistemas; Windows usa ConPTY. Los dispositivos no OpenWrt responden session_error a solicitudes ubus.

Sesiones selladas de extremo a extremo

La versión sigue siendo 1. Mensajes nuevos: OperatorUp open_sealed {session_id, device_id, hello}, sealed_input {session_id, packet}; DeviceDown sealed_open {session_id, hello}, sealed_input, sealed_close {session_id, detach}; DeviceUp / OperatorDown sealed_accept {session_id, accept}, sealed_event {session_id, packet, last}. Se añade el tipo binario 4 = Sealed (carga counter ‖ AEAD(inner_kind ‖ bytes)), DeviceInfo.seal_key y capacidad sealed.

Para sesiones selladas, Exchange solo traduce identificadores, limita concurrencia y enruta: no analiza ni audita la carga (la auditoría solo guarda clave pública, nivel y vencimiento de autorización y resultado final), ni determina permisos (solo comprueba que la cuenta pueda ver el dispositivo). Libera la ruta con last:true. Las rutas selladas solo aceptan tramas Sealed; las normales no aceptan tramas Sealed. agent descarta cualquier texto sin cifrar dirigido a un identificador sellado. Autorización, handshake, derivación de claves, modelo de amenazas se describen en Sesiones selladas de extremo a extremo.