Noctiluca - il semble que l’avenir des logiciels de contrôle à distance n’était pas WebRTC, mais QUIC

Bonjour, je m'appelle unstabler. C’est la première fois que j’écris ici.
Je n’ai pas l’habitude d’écrire souvent, donc le texte est un peu décousu et long, mais merci de votre indulgence !

J’ai commencé à m’obséder pour macOS parce que je n’aime pas macOS

J’utilise principalement des bureaux Linux depuis 2011. Après Ubuntu, Debian et Fedora, j’ai continué à utiliser Arch Linux + KDE Plasma comme OS principal. Pour diverses raisons, j’ai fini par créer en 2021 une entreprise qui fonctionne un peu comme une SSII, et j’ai accepté toutes sortes de missions tant qu’elles étaient intéressantes : C++ embarqué, applications mobiles, sites web simples, etc.

Pendant ce temps, la part des projets de création d’apps iOS a commencé à augmenter. Mais je n’avais pas vraiment envie d’utiliser un Mac. Au début, j’ai essayé de modifier les raccourcis clavier dans tous les sens avec Karabiner, puis je me connectais avec Google Remote Desktop pour travailler, mais c’était beaucoup trop lent, et dans Xcode, certaines saisies clavier ou actions de la souris se comportaient bizarrement, ce qui était très stressant.

Tiens, en y repensant : RDP ! Il y avait xrdp !

RDP m’est soudain revenu à l’esprit. RDP est un protocole développé pour Microsoft Windows, mais il existe une implémentation open source appelée xrdp. Toutefois, xrdp part par défaut du principe qu’on utilise X11, et sur macOS il était possible d’utiliser le partage d’écran natif + un backend VNC, mais dès que la résolution de l’écran n’était pas alignée en 1:1, cela devenait pratiquement inutilisable.

J’ai donc créé un plugin backend xrdp nommé '麗 -ulalaca-', basé sur le backend VNC de xrdp et ScreenCaptureKit, mais cela n’a jamais atteint un niveau vraiment exploitable en usage réel.

• Prise en charge disparue de GFX (H.264) / RFX dans les versions récentes de Windows (mstsc.exe) :
  Au moment où j’ai commencé le développement, la prise en charge des codecs GFX / RemoteFX était déjà en train de disparaître. Le client Linux FreeRDP les prend encore en charge, mais sur les versions actuelles de Windows, il semble qu’il ne reste plus qu’une compression basée sur RLE.
• Difficulté de développement / débogage infernale : en dehors de l’affichage de l’écran, le développement était beaucoup trop difficile, et le débogage l’était tout autant. Au départ, j’étais très motivé et je voulais aussi essayer d’ajouter la sortie audio / la synchronisation du presse-papiers, mais comme je souffrais déjà de TDAH, mon intérêt est vite retombé.

Repartons sur WebRTC ! Mais...

Environ six mois après avoir laissé ulalaca de côté, en imaginant Noctiluca, je me suis dit : « Reprenons proprement avec WebRTC ! ». Mais l’implémentation de WebRTC n’était pas simple non plus.

• Difficulté de personnalisation : pour utiliser les données d’écran comme source vidéo, il fallait récupérer et modifier le code source de Google Chromium. Quand l’encodage matériel a cessé de fonctionner après avoir modifié les paramètres du codec, je n’ai eu d’autre choix que de fouiller dans le code source, d’ajouter des logs, et de tout recompiler à chaque fois pour comprendre pourquoi.
• Impossible de fixer les ports : il fallait un serveur de signalisation, il fallait aussi TURN/STUN, et surtout, il était impossible de fixer les ports sortants ou de réutiliser les ports. C’était un vrai calvaire.
• La malédiction de SCTP : WebRTC DataChannel utilise SCTP en interne. Quand la taille du payload d’un message dépasse le MTU, cela provoque des ralentissements sur les flux vidéo / audio.

Au final, après bien des détours, retour vers QUIC

Épuisé par la complexité de WebRTC, j’ai de nouveau laissé Noctiluca de côté pendant presque six mois. Un jour, en rentrant après être resté à ne rien faire dans un café, QUIC, la base de HTTP/3, m’est soudain revenu à l’esprit. Justement, macOS / iOS fournissent aussi une implémentation de QUIC dans Network.framework, ce qui m’a permis de créer rapidement un prototype à partir du code existant, et au niveau du prototype, les problèmes ci-dessous ont été résolus immédiatement.

• Résolution du Head-of-Line Blocking (HOL) : le plus gros problème des solutions basées sur TCP, ou de WebRTC DataChannel qui utilise SCTP, c’est que si un seul paquet est perdu, toutes les données qui suivent s’arrêtent. Mais avec QUIC, les flux sont indépendants. Même si un paquet audio saute, les entrées souris et les frames vidéo continuent d’arriver.

• Port UDP unique et Connection Migration : contrairement à WebRTC, il n’était pas nécessaire de mettre en place toute une configuration complexe avec serveur de signalisation, STUN/TURN, etc. Il suffit d’ouvrir un seul port UDP, et c’est tout. Même en changeant de point d’accès Wi‑Fi, la connexion restait maintenue grâce à Connection Migration.

Conclusion : je cherche des bêta-testeurs !

Je recrute des bêta-testeurs pour ce logiciel de contrôle à distance nommé Noctiluca, né de toute cette histoire.

• Il utilise un protocole maison nommé Sirius, conçu sur la base de QUIC.

  • Dès que les spécifications et autres éléments seront finalisés, je prévois de le publier en open source !

• Il prend en charge H.264 / H.265 (HEVC).

  • Il prend aussi en charge des codecs d’image traditionnels à base de tuiles pour les environnements VM (MJPG, RLE, WebP).

• Il prend en charge la transmission de contenus HDR. (expérimental)

• Les exigences de codec peuvent être négociées entre client et serveur.

• Il prend en charge l’authentification PAM (nom d’utilisateur-mot de passe), mot de passe seul, et via clé SSH.

• Les fonctionnalités peuvent être étendues par plugin. Plus tard, je prévois d’ajouter par exemple fail2ban comme fonctionnalité supplémentaire.

  • Il est aussi possible d’écrire directement ses propres plugins pour étendre le mécanisme d’authentification.

• Le client n’existe actuellement que pour iOS / macOS.

  • Je prévois de développer un client Linux / Windows basé sur Qt / C++ !

Jusqu’au jour où le développement d’apps iOS sera possible depuis mon laptop Linux !
Aujourd’hui encore, mon voyage pour revenir à mon laptop Linux continue.

Merci.

(+ En réalité, je ne savais pas si je pouvais poster directement ici un lien Google Drive, donc j’ai mis pour l’instant le lien vers le post X que j’avais publié lors de la présentation précédente..!)

• Lien Google Drive de la première version de test : https://drive.google.com/drive/folders/1r4m7lGZ-f988dp_piLAEwlJRLPODPNQq?usp=drive_link

(++ C’est un sous-produit créé en faisant du vibe coding pendant le développement de Noctiluca (?), mais merci aussi de vous y intéresser..!)

• swift-msquic : un module wrapper conçu pour faciliter l’utilisation de MsQuic en Swift sur iOS / macOS !
• Xuanxue : un module permettant d’effectuer des signatures / vérifications de signature avec des clés SSH en Swift ! J’ai donné ce nom parce que, par pure flemme, je voulais tout faire sans effort !

[channprj]

C’est génial !! 👍🏻

[jjpark78]

J’utilise Parsec.

[jjpark78]

À part la contrainte d’avoir la même taille d’écran, ça me semble être le meilleur outil d’accès à distance.
Le fait que l’iPad ne soit pas pris en charge m’est complètement égal.

[lux1024]

J’utilise aussi Parsec, et j’ai été assez choqué d’apprendre que ça ne fonctionnait vraiment pas sur mobile. Je n’en revenais pas… haha.

En fait, pour le développement iOS/macOS, j’ai l’impression que le mieux reste simplement d’utiliser un Mac mini ou un MacBook connecté en KVM, même si c’est quand même un peu pénible.

[unstabler]

En réalité, si je peux continuer à développer Noctiluca, j’aimerais créer une fonctionnalité similaire au concept de « RemoteApp » de Microsoft RDP. Et aussi une fonction de redirection USB !

Si je branche mon iPhone à mon ThinkPad et qu’il est reconnu de la même façon sur le Mac dans l’autre pièce, et que je peux n’extraire et utiliser que la fenêtre Xcode au lieu du « plein écran » du Mac, je crois que je serais vraiment heureux.

[unstabler]

Nous sommes donc aussi en train de concevoir / implémenter des fonctionnalités liées..!

Rien n’est encore vraiment structuré pour le moment, donc je n’ai rien d’autre à vous montrer que ceci T_T

https://gist.github.com/unstabler/25679baab3a65a3c19f747c38f30c1b3

[moderator]

J’ai remplacé le lien d’origine par un lien Drive, et le lien vers le post X a été intégré dans le corps de l’article.

[bus710]

Je me demandais comment accéder à mon Mac, mais je n’avais qu’une vague idée que ça pourrait peut-être se faire d’une manière ou d’une autre avec jetkvm et tailscale.
Avec la méthode de l’article, ce serait donc possible même sans KVM.