Gateway
ब्रिज प्रोटोकॉल
यह क्यों मौजूद था
- सुरक्षा सीमा: संपूर्ण Gateway API सतह के बजाय एक छोटी अनुमति-सूची उपलब्ध कराता था।
- पेयरिंग + Node पहचान: Node प्रवेश का स्वामित्व Gateway के पास था और वह प्रति-Node टोकन से जुड़ा था।
- डिस्कवरी UX: Node LAN पर Bonjour के माध्यम से Gateway खोज सकते थे या किसी टेलनेट पर सीधे कनेक्ट कर सकते थे।
- लूपबैक WS: SSH के माध्यम से टनल किए जाने तक संपूर्ण WS नियंत्रण तल स्थानीय रहता था।
ट्रांसपोर्ट
- TCP, प्रति पंक्ति एक JSON ऑब्जेक्ट (JSONL)।
- वैकल्पिक TLS (
bridge.tls.enabled: true)। - डिफ़ॉल्ट लिसनर पोर्ट
18790था।
TLS सक्षम होने पर, डिस्कवरी TXT रिकॉर्ड में bridgeTls=1 के साथ गैर-गोपनीय संकेत के रूप में bridgeTlsSha256 शामिल होता था। Bonjour/mDNS TXT रिकॉर्ड अप्रमाणित होते हैं; अन्य आउट-ऑफ़-बैंड सत्यापन के बिना क्लाइंट विज्ञापित फ़िंगरप्रिंट को आधिकारिक पिन नहीं मान सकते थे।
हैंडशेक और पेयरिंग
- क्लाइंट Node मेटाडेटा और टोकन (यदि पहले से पेयर किया गया हो) के साथ
helloभेजता है। - पेयर न होने पर, Gateway
error(NOT_PAIRED/UNAUTHORIZED) से उत्तर देता है। - क्लाइंट
pair-requestभेजता है। - Gateway अनुमोदन की प्रतीक्षा करता है, फिर
pair-okऔरhello-okभेजता है।
hello-ok पहले serverName लौटाता था; होस्ट की गई Plugin सतहें अब वर्तमान Gateway प्रोटोकॉल पर pluginSurfaceUrls के माध्यम से विज्ञापित की जाती हैं (Canvas/A2UI में pluginSurfaceUrls.canvas का उपयोग होता है)।
फ़्रेम
क्लाइंट से Gateway:
req/res: सीमित-दायरे वाली Gateway RPC (चैट, सत्र, कॉन्फ़िगरेशन, स्वास्थ्य, वॉइसवेक, skills.bins)।event: Node संकेत (वॉइस ट्रांसक्रिप्ट, एजेंट अनुरोध, चैट सदस्यता, निष्पादन जीवनचक्र)।
Gateway से क्लाइंट:
invoke/invoke-res: Node कमांड (canvas.*,camera.*,screen.record,location.get,sms.send)।event: सदस्यता लिए गए सत्रों के लिए चैट अपडेट।ping/pong: कनेक्शन सक्रिय रखने के संकेत।
अनुमति-सूची प्रवर्तन src/gateway/server-bridge.ts में मौजूद था (हटा दिया गया)।
निष्पादन जीवनचक्र इवेंट
Node पूर्ण हुई system.run गतिविधि प्रदर्शित करने के लिए exec.finished उत्सर्जित करते थे, जिसे Gateway द्वारा सिस्टम इवेंट में मैप किया जाता था (पुराने Node exec.started भी उत्सर्जित कर सकते थे)। exec.denied किसी अस्वीकृत system.run प्रयास को सिस्टम इवेंट कतारबद्ध किए या एजेंट कार्य को सक्रिय किए बिना अंतिम अस्वीकृति के रूप में चिह्नित करता था।
पेलोड फ़ील्ड (जब तक उल्लेख न किया गया हो, सभी वैकल्पिक):
| फ़ील्ड | टिप्पणियाँ |
|---|---|
sessionKey |
आवश्यक। इवेंट सहसंबंध के लिए एजेंट सत्र और, exec.finished के लिए, सिस्टम इवेंट डिलीवरी। |
runId |
समूहबद्ध करने के लिए अद्वितीय निष्पादन आईडी। |
command |
अपरिष्कृत या स्वरूपित कमांड स्ट्रिंग। |
exitCode, timedOut, output |
पूर्णता विवरण (केवल समाप्त होने पर)। |
reason |
अस्वीकृति का कारण (केवल अस्वीकार होने पर)। |
ऐतिहासिक टेलनेट उपयोग
- ब्रिज को किसी टेलनेट IP से बाइंड करें:
~/.openclaw/openclaw.jsonमेंbridge.bind: "tailnet"(केवल ऐतिहासिक;bridge.*अब मान्य कॉन्फ़िगरेशन नहीं है)। - क्लाइंट MagicDNS नाम या टेलनेट IP के माध्यम से कनेक्ट होते थे।
- Bonjour नेटवर्क सीमाएँ पार नहीं करता; अन्यथा वाइड-एरिया DNS-SD या मैन्युअल होस्ट/पोर्ट आवश्यक था।
संस्करण प्रबंधन
ब्रिज निहित रूप से v1 था और उसमें न्यूनतम/अधिकतम समन्वय नहीं था। वर्तमान Node/ऑपरेटर क्लाइंट WebSocket Gateway प्रोटोकॉल का उपयोग करते हैं, जो प्रोटोकॉल संस्करण सीमा पर समन्वय करता है।