Noctiluca - लगता है रिमोट कंट्रोल सॉफ़्टवेयर का भविष्य WebRTC नहीं, बल्कि QUIC था
(drive.google.com)नमस्ते, मैं unstabler हूँ। यह मेरी पहली पोस्ट है।
मैं आम तौर पर अक्सर लिखता नहीं हूँ, इसलिए यह थोड़ा बेतरतीब और लंबा लेख है, कृपया सहन करें!
macOS से नफ़रत करते-करते मैं macOS पर अटक गया
मैं 2011 से मुख्य रूप से Linux डेस्कटॉप इस्तेमाल करता आया हूँ। Ubuntu, Debian, Fedora से होते हुए मैं Arch Linux + KDE Plasma को अपने मुख्य OS के रूप में लगातार इस्तेमाल करता रहा हूँ। कई तरह की परिस्थितियों के कारण, 2021 से मैंने एक ऐसी कंपनी शुरू की जो लगभग SI कंपनी की तरह चलती है, और embedded C++ हो, mobile app हो, या साधारण website हो, अगर काम मज़ेदार लगता था तो सब ले लिया।
इसी दौरान iOS app बनाने वाले काम का हिस्सा धीरे-धीरे बढ़ने लगा। लेकिन मैं Mac ज़्यादा इस्तेमाल नहीं करना चाहता था। शुरू में Karabiner से key bind इधर-उधर बदलकर देखा, फिर Google Remote Desktop से कनेक्ट होकर काम भी किया, लेकिन वह बहुत धीमा था, और Xcode में key input या mouse का कुछ व्यवहार अजीब था, जिससे काफ़ी stress हुआ।
तभी याद आया, RDP! xrdp भी तो था!
अचानक RDP का ख़याल आया। RDP मूल रूप से Microsoft Windows के लिए विकसित किया गया protocol है, लेकिन xrdp नाम का उसका एक open source implementation भी था। लेकिन xrdp मूल रूप से X11 उपयोग को ध्यान में रखकर बना है, और macOS में default screen sharing + VNC backend का संयोजन इस्तेमाल किया जा सकता था, पर अगर screen resolution 1:1 न मिले तो वह लगभग अनुपयोगी हो जाता था।
इसलिए मैंने xrdp के VNC backend और ScreenCaptureKit के आधार पर ''麗 -ulalaca-' नाम का एक xrdp backend plugin बनाया, लेकिन वह अभी तक वास्तविक उपयोग लायक स्तर तक नहीं पहुँच पाया।
- Windows के नए version (mstsc.exe) में गायब हो चुका GFX (H.264) / RFX support:
जब मैंने development शुरू किया, तब तक GFX / RemoteFX codec support हटना शुरू हो चुका था। Linux client FreeRDP में अब भी इसका support है, लेकिन मौजूदा Windows version में शायद सिर्फ़ RLE-आधारित compression बचा है। - बेहद कठिन development / debugging: screen display feature के अलावा development बहुत कठिन था, और debugging उससे भी कठिन। शुरू में मैं बड़े उत्साह के साथ audio output / clipboard sync जैसी चीज़ें भी बनाना चाहता था, लेकिन मुझे ADHD भी है, इसलिए दिलचस्पी जल्दी ठंडी पड़ गई।
WebRTC से फिर एक बार बनाकर देखें! लेकिन...
ulalaca को छोड़ देने के लगभग आधे साल बाद, Noctiluca की योजना बनाते समय मैंने सोचा, ‘चलो WebRTC के साथ इसे एक बार ठीक से फिर बनाकर देखते हैं!’ लेकिन WebRTC implementation भी आसान नहीं था।
- customization की कठिनाई: screen data को video source की तरह इस्तेमाल करने के लिए Google Chromium का source code लेकर उसमें बदलाव करना पड़ा। codec parameter बदलने के बाद जब hardware encoding काम नहीं करती थी, तो वजह पता करने के लिए source code खंगालना पड़ता था, log जोड़ने पड़ते थे, और हर बार दोबारा build करना पड़ता था।
- port fix नहीं कर सकते: signaling server भी चाहिए, TURN/STUN भी चाहिए, और सबसे बड़ी बात यह कि outgoing port को fix करना और port reuse करना संभव नहीं था। यह बहुत तकलीफ़देह था।
- SCTP का अभिशाप: WebRTC DataChannel अंदर से SCTP का उपयोग करता है। समस्या यह है कि अगर किसी एक message का payload size MTU से बड़ा हो जाए, तो video / audio stream में lag आना शुरू हो जाता है।
आख़िरकार घूम-फिरकर QUIC पर पहुँचे
WebRTC की जटिलता से थककर, इस बार भी मैंने Noctiluca को लगभग आधे साल तक छोड़ दिया। एक दिन कैफ़े में यूँ ही बैठे-बैठे लौटते समय अचानक मुझे QUIC याद आया, जो HTTP/3 की नींव माना जाता है। संयोग से macOS / iOS में Network.framework के भीतर QUIC implementation भी उपलब्ध था, इसलिए मौजूदा source code के आधार पर prototype जल्दी बन गया, और prototype स्तर पर ही नीचे दी गई समस्याएँ तुरंत हल हो गईं।
-
Head-of-Line Blocking (HOL) का समाधान: TCP-आधारित solutions, या SCTP इस्तेमाल करने वाले WebRTC DataChannel की सबसे बड़ी समस्या यह है कि अगर एक packet खो जाए तो उसके बाद आने वाला सारा data रुक जाता है। लेकिन QUIC में stream स्वतंत्र होते हैं। एक audio packet छूट भी जाए, तो mouse input या video frame लगातार आते रहते हैं।
-
एकल UDP port और Connection Migration: WebRTC की तरह signaling server, STUN/TURN जैसी जटिल व्यवस्था की ज़रूरत नहीं पड़ी। बस एक UDP port खोलिए और काम ख़त्म। Wi‑Fi AP बदलने पर भी Connection Migration की वजह से कनेक्शन बना रहा।
निष्कर्ष: beta tester आमंत्रित हैं!
इन्हीं अनुभवों के साथ मैं 'Noctiluca' नाम के इस remote control software के लिए beta tester आमंत्रित कर रहा हूँ।
-
यह QUIC-आधारित, स्वयं डिज़ाइन किया गया 'Sirius' protocol उपयोग करता है।
- spec आदि तय होते ही इसे open source के रूप में जारी करने की योजना है!
-
H.264 / H.265 (HEVC) को support करता है।
- VM environment के लिए पारंपरिक tile-based image codec (MJPG, RLE, WebP) भी support करता है।
-
HDR content transmission को support करता है। (experimental)
-
client-server के बीच codec requirements पर negotiation किया जा सकता है।
-
PAM (username-password), password-only, और SSH key का उपयोग करने वाली authentication को support करता है।
-
plugin के ज़रिए features बढ़ाए जा सकते हैं। आगे चलकर fail2ban आदि implement करके अतिरिक्त feature के रूप में देने की योजना है।
- plugin सीधे लिखकर authentication mechanism को भी बढ़ाया जा सकता है।
-
client अभी केवल iOS / macOS version में उपलब्ध है।
- Qt / C++ आधारित Linux / Windows client भी विकसित करने की योजना है!
उस दिन तक, जब मैं अपने Linux laptop से iOS app development कर सकूँ!
आज भी अपने Linux laptop की ओर वापस लौटने की मेरी यात्रा जारी है।
धन्यवाद।
(+ सच कहूँ तो मुझे पता नहीं था कि Google Drive link सीधे यहाँ डालना ठीक है या नहीं, इसलिए फ़िलहाल मैंने वह X post लिंक किया है जो पहले परिचय देते समय पोस्ट किया था..!)
- पहले test version का Google Drive link: https://drive.google.com/drive/folders/1r4m7lGZ-f988dp_piLAEwlJRLPODPNQq?usp=drive_link
(++ Noctiluca विकसित करते समय vibe coding में बना एक side project जैसा उप-उत्पाद(?) है, इसे भी देखिएगा..!)
- swift-msquic: यह एक wrapper module है, जिससे iOS / macOS पर MsQuic को Swift में आसानी से इस्तेमाल किया जा सके!
- Xuanxue: यह एक module है जो Swift में SSH key का उपयोग करके signing / signature verification करने देता है! मैं इतना आलसी हूँ कि हर चीज़ आसान तरीके से करना चाहता था, इसलिए इसका यह नाम रखा!
8 टिप्पणियां
कमाल है!! 👍🏻
मैं Parsec इस्तेमाल करता हूँ
मॉनिटर का साइज़ एक जैसा होना चाहिए वाली सीमा को छोड़ दें, तो यह सबसे बेहतरीन remote access टूल लगता है।
iPad सपोर्ट नहीं है, लेकिन वह मेरे लिए बिल्कुल भी मायने नहीं रखता।
मैं भी Parsec इस्तेमाल करता हूँ, और यह जानकर सच में थोड़ा झटका लगा कि यह मोबाइल पर ठीक से नहीं चलता। मैंने सोचा भी नहीं था... हा हा
असल में iOS/macOS डेवलपमेंट के लिए बस Mac mini या MacBook को KVM से जोड़कर इस्तेमाल करना ही सबसे बढ़िया लगता है, लेकिन वह भी काफ़ी झंझट वाला है।
असल में, अगर मैं Noctiluca का डेवलपमेंट जारी रख सका, तो मैं Microsoft RDP के 'RemoteApp' कॉन्सेप्ट जैसी कोई फ़ीचर बनाना चाहूँगा। और USB redirection फ़ीचर भी!
अगर मैं अपने ThinkPad में iPhone लगाऊँ और वह दूसरे कमरे में रखे Mac पर भी बिल्कुल वैसे ही पहचान लिया जाए, और Mac के 'full screen' की बजाय सिर्फ़ Xcode विंडो निकालकर इस्तेमाल कर सकूँ, तो मुझे सच में बहुत खुशी होगी।
इसलिए उससे संबंधित फीचर भी डिज़ाइन / इम्प्लीमेंटेशन के दौरान हैं..!
अभी तक कुछ भी ठीक से व्यवस्थित नहीं हुआ है, इसलिए दिखाने लायक मेरे पास बस यही है T_T
https://gist.github.com/unstabler/25679baab3a65a3c19f747c38f30c1b3
मूल लिंक को Drive लिंक से बदल दिया गया है, और X पोस्ट लिंक को लेख के भीतर जोड़ दिया गया है।
मैं सोच रहा था कि Mac तक कैसे पहुँचूं, लेकिन बस इतना धुंधला-सा विचार था कि शायद jetkvm और tailscale से किसी तरह हो जाएगा।
अगर लेख में बताया गया तरीका अपनाएँ, तो KVM के बिना भी यह संभव होगा।