Comprobar la luz desde la sala sin volver corriendo al portátil, por qué bastó con SSE en lugar de websockets y qué pasa si no pones PIN en un Wi-Fi abierto.
Los escenarios por los que se monta esto
Comprobar desde la sala. Recorres las filas, vas lanzando cues sobre la
marcha y miras cómo queda desde las butacas. Sin esto, ajustar ángulos y
niveles se convierte en una carrera de relevos: cinco pasos allá, cinco
acá, cuarenta veces.
Enfocar desde el escenario. Estás bajo el aparato, lo seleccionas en el
móvil, subes intensidad y ves la mancha donde estás, no a través de una
cámara.
Una segunda persona en el pase. El ayudante lleva los GO por el texto y
tú corriges niveles. O al revés.
Montaje. Blackout desde el móvil cuando hay que apagar ya y estás
subido a una escalera.
La consola se queda con el operador. El móvil no es un sustituto, es una
segunda mano.
Por dentro: por qué SSE y no websockets
Una decisión de ingeniería que conviene explicar, porque es
contraintuitiva.
Aquí los datos van en dos direcciones: hacia abajo, al móvil, el estado (cue
activo, presets encendidos, posición del master); hacia arriba, los
comandos. El reflejo dice: intercambio bidireccional, usa WebSocket.
Nosotros pusimos Server-Sent Events hacia abajo y POST normales hacia
arriba, y he aquí por qué.
Hacia arriba vuelan pulsaciones con el dedo: unas pocas por segundo en el
caso más animado. Para ese caudal un POST no es peor que una trama de
websocket, y se depura con curl.
Hacia abajo fluye el estado, y fluye sólo hacia abajo. SSE es
literalmente una respuesta HTTP que no termina: el servidor mantiene la
conexión y le va añadiendo líneas. Sin framing, sin apretón de manos, sin
ping-pong para saber si el cliente sigue vivo.
La diferencia de precio: un WebSocket en Node significa o una dependencia
externa o tu propia implementación del RFC 6455 con framing y enmascarado.
SSE es un res.write() en un bucle. Para la función «enseñarle al móvil qué
cue está activo», lo segundo es más honesto.
Ventaja añadida: SSE se reconecta solo. El móvil se durmió, el Wi-Fi
parpadeó, y el navegador restaura el flujo sin una sola línea de código
nuestro. Con un websocket eso lo habríamos escrito a mano, y con fallos.
El estado se envía con un throttling de 120 ms y deduplicación: mientras el
operador arrastra un fader, no salen instantáneas en cada trama.
Los comandos van por el mismo camino que MIDI y OSC
Esto es una cuestión de principio. El móvil no tiene su propia vía hacia el
estado interno de la aplicación: su comando pasa por el mismo despachador
que una pulsación de pad en un controlador MIDI o un mensaje OSC desde una
tableta.
El motivo es pragmático: tres vías paralelas a una misma acción son tres
juegos de fallos y tres sitios donde alguien olvidó actualizar la lógica.
Una vía, un juego.
El propio servidor HTTP vive en el proceso principal de la aplicación, junto
a DMX y OSC. La ventana de interfaz no abre puertos.
Sobre seguridad: el PIN no es decorativo
El servidor escucha en todas las interfaces de red; si no, el móvil no
llegaría. Es decir, lo ve toda la red del recinto.
Imagina lo que significa en un concierto: un Wi-Fi de invitados con
trescientas personas y una página abierta con un botón de blackout. No hace
falta mala intención: basta con curiosidad y una dirección adivinada por
casualidad del estilo 192.168.1.42:7331.
Por eso:
- Pon un PIN. Un PIN vacío significa «que entre cualquiera de esta red»,
y los ajustes lo advierten sin rodeos. Con PIN el móvil recibe una cookie
de sesión (HttpOnly, 12 horas) y no hay que reescribirlo cada vez.
- La fuerza bruta se corta: más de diez intentos desde una dirección por
minuto y deja de responder. Un PIN de cuatro cifras son diez mil intentos,
o sea diecisiete horas a ese ritmo en vez de un minuto.
- Cambiar el PIN echa a todos. Se fue el ayudante con su móvil: cambias
el PIN y su sesión muere con las demás.
Lo ideal, claro, es una red separada para el espectáculo a la que nadie de
fuera pueda llegar. Pero como sabemos que en la realidad habrá un solo switch
para todo, el PIN viene activado por defecto por algo.
Conexión, y el detalle que lo estropea todo
En los ajustes se muestra la dirección y un código QR: apuntas la cámara
en vez de teclear una IP a oscuras. Ahorra treinta segundos y una errata.
Si la página no abre, casi siempre es el aislamiento de clientes: el Wi-Fi de
invitados suele estar configurado para que los dispositivos no se vean entre
sí. Se comprueba al instante: el móvil y el portátil deben verse por ping.
Y lo más fastidioso, que conviene hacer antes: desactiva el bloqueo
automático de pantalla. El móvil se apaga justo cuando hay que dar el GO, y
lo desbloqueas con una mano subido a la escalera.