Noctiluca - Parece que el futuro del software de control remoto no era WebRTC, sino QUIC
(drive.google.com)Hola, soy unstabler. Es la primera vez que escribo un artículo.
No suelo escribir muy seguido, así que les pido paciencia con este texto algo desordenado y largo.
Empecé a obsesionarme con macOS porque no me gusta macOS
Desde 2011 he usado principalmente Linux en el escritorio. Pasé por Ubuntu, Debian y Fedora, y seguí usando Arch Linux + KDE Plasma como mi sistema operativo principal. Por distintas circunstancias, desde 2021 terminé fundando una empresa que funciona de manera parecida a una consultora SI, y acepté todo tipo de trabajos siempre que fueran interesantes: C++ embebido, apps móviles, sitios web sencillos, lo que fuera.
Mientras tanto, la proporción de trabajo para crear apps de iOS fue aumentando poco a poco. Pero no quería usar mucho una Mac. Al principio intenté cambiar los atajos de teclado con Karabiner y cosas así, y también trabajaba conectándome por Google Remote Desktop, pero era demasiado lento, y además en Xcode el teclado o el mouse se comportaban raro en algunas situaciones, así que me generaba muchísimo estrés.
Entonces me acordé de RDP. ¡Claro, estaba xrdp!
De pronto se me vino a la mente RDP. Aunque RDP es un protocolo desarrollado para Microsoft Windows, existía una implementación de código abierto llamada xrdp. Pero xrdp asume por defecto el uso de X11, y en macOS se podía usar la combinación de compartición de pantalla nativa + backend VNC, aunque si la resolución de pantalla no coincidía 1:1, llegaba al punto de ser prácticamente imposible de usar.
Por eso terminé creando un plugin backend para xrdp llamado '麗 -ulalaca-', basado en el backend VNC de xrdp y en ScreenCaptureKit, pero no logré llevarlo hasta un nivel realmente utilizable.
- Soporte de GFX (H.264) / RFX que desapareció en las versiones recientes de Windows (
mstsc.exe):
Cuando empecé a desarrollarlo, el soporte para los códecs GFX / RemoteFX ya estaba empezando a desaparecer. En FreeRDP, un cliente para Linux, todavía seguía habiendo soporte, pero en las versiones actuales de Windows parece que solo queda compresión basada en RLE. - Dificultad infernal para desarrollar y depurar: aparte de la visualización de pantalla, todo lo demás era demasiado difícil de desarrollar, y depurar también lo era. Al principio tenía muchísimas ganas e incluso quería implementar salida de audio, sincronización de portapapeles y demás, pero como ya sufría de ADHD, perdí el interés muy rápido.
¡Intentemos hacerlo otra vez con WebRTC! Pero...
Tras dejar abandonado ulalaca durante casi medio año, mientras pensaba en Noctiluca se me ocurrió algo como: “¡Intentemos hacerlo bien esta vez con WebRTC!”. Pero implementar WebRTC tampoco era nada sencillo.
- Dificultad para personalizarlo: para usar los datos de pantalla como fuente de video, tuve que descargar y modificar el código fuente de Google Chromium. Cuando después de cambiar parámetros del códec la codificación por hardware dejó de funcionar, para averiguar por qué tuve que meterme a revisar el código, agregar logs y recompilar cada vez.
- Imposible fijar puertos: hacía falta un servidor de signaling, también TURN/STUN y, sobre todo, no era posible fijar el puerto saliente ni reutilizar puertos. Fue una pesadilla.
- La maldición de SCTP: WebRTC DataChannel usa SCTP internamente. Si el tamaño del payload de un mensaje supera el MTU, empieza a introducir lag en los streams de video y audio.
Al final, después de tanto rodeo, terminé en QUIC
Cansado de la complejidad de WebRTC, también dejé Noctiluca abandonado durante casi medio año. Un día, de regreso a casa después de estar distraído en un café, de repente pensé en QUIC, la base de HTTP/3. Justo en macOS / iOS también había una implementación de QUIC disponible en Network.framework, así que pude crear rápidamente un prototipo basándome en el código existente, y a nivel de prototipo los siguientes problemas se resolvieron de inmediato.
-
Resolución del Head-of-Line Blocking (HOL): el mayor problema de las soluciones basadas en TCP, o de WebRTC DataChannel cuando usa SCTP, es que si se pierde un solo paquete, todos los datos que vienen detrás se detienen. Pero en QUIC los streams son independientes. Aunque falle un paquete de audio, las entradas del mouse o los frames de video siguen llegando sin parar.
-
Un solo puerto UDP y Connection Migration: no hacía falta montar algo complejo como en WebRTC con servidor de signaling, STUN/TURN y demás. Bastaba con abrir un solo puerto UDP. Incluso al cambiar de punto de acceso Wi‑Fi, la conexión se mantenía gracias a Connection Migration.
Conclusión: ¡estoy buscando beta testers!
Estoy buscando beta testers para este software de control remoto llamado Noctiluca, que nació a partir de toda esta historia.
-
Usa un protocolo propio llamado
Sirius, basado en QUIC.- Cuando pronto queden definidos detalles como la especificación, planeo publicarlo como código abierto.
-
Soporta H.264 / H.265 (HEVC).
- También soporta códecs de imagen tradicionales basados en tiles para entornos VM (MJPG, RLE, WebP).
-
Soporta la transmisión de contenido HDR. (experimental)
-
Permite negociar requisitos de códecs entre cliente y servidor.
-
Soporta autenticación con PAM (usuario-contraseña), solo contraseña y llave SSH.
-
Sus funciones se pueden ampliar mediante plugins. Más adelante planeo implementar cosas como fail2ban y ofrecerlas como funciones adicionales.
- También se pueden escribir plugins propios para ampliar el mecanismo de autenticación.
-
Por ahora, el cliente solo existe para iOS / macOS.
- Tengo previsto desarrollar clientes para Linux / Windows basados en Qt / C++.
¡Hasta el día en que pueda desarrollar apps de iOS desde mi laptop con Linux!
Incluso hoy, sigue mi camino de regreso a mi laptop con Linux.
Gracias.
(+ La verdad no sabía si estaba bien poner aquí directamente un enlace de Google Drive, así que por ahora dejo el post de X que compartí cuando lo presenté antes como enlace...!)
- Enlace de Google Drive para la primera versión de prueba: https://drive.google.com/drive/folders/1r4m7lGZ-f988dp_piLAEwlJRLPODPNQq?usp=drive_link
(++ Mientras desarrollaba Noctiluca, también surgieron como subproductos hechos con vibe coding(?), así que también se los recomiendo...!)
- swift-msquic: un módulo wrapper hecho para poder usar MsQuic fácilmente desde Swift en iOS / macOS.
- Xuanxue: un módulo que permite realizar firmas y verificación de firmas usando llaves SSH en Swift. Le puse ese nombre porque soy tan flojo que quería resolver todo de la manera más fácil posible.
8 comentarios
¡Qué genial!! 👍🏻
Uso Parsec.
Creo que es la mejor herramienta de acceso remoto, si quitamos la limitación de que el tamaño de los monitores tiene que ser igual.
Que no funcione en iPad para mí no importa en absoluto.
Yo también uso parsec, y la verdad creo que me impactó un poco enterarme de que de verdad no funciona en móvil. Jamás pensé que sería así... jaja
La verdad, para desarrollo en iOS/macOS, parece que lo mejor es simplemente usar una Mac mini o una MacBook conectada por KVM, aunque sí da algo de pereza.
La verdad, si pudiera seguir desarrollando Noctiluca, me gustaría crear una función parecida al concepto de "RemoteApp" de Microsoft RDP. ¡Y también una función de redirección USB!
Si conectara mi iPhone a mi ThinkPad y se reconociera igual en la Mac que está en otra habitación, y además pudiera sacar y usar solo la ventana de Xcode en lugar de la "pantalla completa" de la Mac, creo que sería realmente feliz.
Así que también estamos diseñando e implementando funciones relacionadas..!
Como todavía no hemos organizado nada en absoluto, lo único que puedo mostrarles por ahora es esto T_T
https://gist.github.com/unstabler/25679baab3a65a3c19f747c38f30c1b3
Reemplacé el enlace original por un enlace de Drive, y el enlace de la publicación en X quedó vinculado dentro del texto.
Había estado pensando cómo acceder a la Mac, pero solo tenía la idea vaga de que de alguna manera podría arreglármelas con jetkvm y tailscale.
Con el método del artículo, parece que incluso sería posible sin KVM.