C-toxcore: फ़ीचर प्रस्ताव: नेटवर्क बाउंसर

मुझे लगता है कि यह सुविधा शायद बॉट में बेहतर तरीके से लागू की गई है, न कि कोर लाइब्रेरी में।

आपको एक बाउंसर लाइब्रेरी लिखने में सक्षम होना चाहिए जो tox.h इंटरफ़ेस को उजागर करती है ताकि क्लाइंट को इसके विरुद्ध बनाया जा सके जैसे कि यह टॉक्सकोर था, बिना किसी क्लाइंट कोड को बदलने की आवश्यकता के। उदाहरण के लिए, इस बाउंसर लाइब्रेरी में क्लाइंट tox_bootstrap() फ़ंक्शन के लिए पहली कॉल को एड्रेस के रूप में माना जा सकता है: बाउंसर डेमॉन का पबकी जिसे बाउंसर लाइब्रेरी से कनेक्ट होना चाहिए। कनेक्शन स्थापित होने के बाद, क्लाइंट पर सभी tox_ फ़ंक्शन रिमोट बाउंसर के लिए RPC होंगे, उदाहरण के लिए tox_friend_send_message() करने वाला क्लाइंट डेमॉन को एक RPC भेजकर उस मसाज को हमारे पास भेजने के लिए कहेगा। ओर से और क्लाइंट को वापस देने के लिए फ़ंक्शन कोड हमें वापस कर दें। बाउंसर लाइब्रेरी दूरस्थ सर्वर पर चल रहे बाउंसर डेमॉन के साथ संचार करने के लिए किसी भी चीज़ का उपयोग कर सकती है, सादे HTTPS से (जो शायद आप चाहते हैं कि आप नेटवर्क के उपयोग को कम करना चाहते हैं) टोक्सकोर के कस्टम पैकेट में।

हाँ, मैं @ अचानक 6 से सहमत हूं, यह कुछ ऐसा है जो एक अलग पुस्तकालय होना चाहिए, न कि टोक्सकोर पुस्तकालय का हिस्सा।

मैंने आरपीसी पुस्तकालय के रूप में भी नहीं सोचा था, लेकिन एक बॉट की तरह जो केवल संदेशों को संग्रहीत करता है और उन्हें टेक्स्ट कमांड पर अग्रेषित करता है।

आप बॉट के साथ कैसे संवाद करेंगे? यदि यह एक Tox bot होता, तो क्या आपको DHT से कनेक्ट होने की आवश्यकता नहीं होती, जिससे zer0def बचना चाहता है?

@ अचानक 6 मैं एक बॉट के बजाय आईआरसी बाउंसर के संदर्भ में अधिक सोच रहा था। सुनिश्चित नहीं हैं कि आप आईआरसी बाउंसर से परिचित हैं, तो बस क्यूटॉक्स क्लाइंट की कल्पना करें, जो एक जीयूआई + टॉक्सकोर है, लेकिन आपकी स्थानीय मशीन पर जीयूआई और टॉक्सकोर चलने के बजाय आप अपनी मशीन पर चल रहे जीयूआई को चलाएंगे लेकिन जीयूआई को टॉक्सकोर चलाएंगे। के साथ संचार एक दूरस्थ सर्वर पर चल रहा है। आप इसे एक पुस्तकालय लिखकर प्राप्त कर सकते हैं जो टॉक्सकोर होने का दिखावा करता है, ताकि qTox बिना किसी कोड परिवर्तन के इसके खिलाफ संकलन कर सके, लेकिन वास्तव में यह एक टोक्सकोर नहीं होगा, बल्कि एक पुस्तकालय होगा जो रिमोट टॉक्सकोर इंस्टेंस के साथ संचार करता है।

लेकिन क्या यह उन पूर्ण नोड्स में लागू नहीं किया गया है जिनका उपयोग मोबाइल क्लाइंट टीसीपी मोड के माध्यम से करते हैं? मेरी सर्वोत्तम समझ के अनुसार टीसीपी मोड डीएचटी नेटवर्क में भाग नहीं लेता है।

@dingosan आपको अभी भी हर समय टीसीपी नोड से जुड़े रहने की जरूरत है। जहां तक ​​मुझे समझ में आया, एक बाउंसर भी संदेशों को संग्रहीत करेगा?

@ अचानक 6 यह शायद लॉग स्थिरता बनाए रखना चाहिए, अन्यथा आपके क्लाइंट को टीसीपी नोड के रूप में चलाना शायद पर्याप्त होगा

नमस्ते, मैं टॉक्सकोर प्रोटोकॉल को संशोधित किए बिना इस तरह कुछ काम कर रहा हूं।
यह आईआरसी की तरह बाउंसर नहीं है, बल्कि पुल की तरह है।
यह मूल प्रोग्राम क्लाइंट और वेब ऐप दोनों का समर्थन करने के लिए gRPC/websock का उपयोग करता है।
ब्रिज ऑनलाइन होने पर सभी संदेशों को संग्रहीत करता है। और सभी ब्रिज के क्लाइंट सिंक्रनाइज़ किए गए संदेश प्राप्त कर सकते हैं।
क्लाइंट सभी इतिहास संदेशों को खींच सकते हैं, और कई क्लाइंट ब्रिज की मदद से संदेशों को एक दूसरे के साथ सिंक कर सकते हैं।

यह कार्य प्रगति पर है, अभी भी एक डेमो है, कोई भी दिलचस्प व्यक्ति देख सकता है:
https://github.com/envsh/tox-homeserver

समस्या अब समूह अस्थायी है, समूह को फिर से बनाने के बाद समूह संदेशों को मर्ज करने का कोई अच्छा तरीका नहीं है।

नीट :) बहुत बढ़िया लगता है!

समस्या अब समूह अस्थायी है, समूह को फिर से बनाने के बाद समूह संदेशों को मर्ज करने का कोई अच्छा तरीका नहीं है।

हमें qTox में भी यही समस्या है। लगातार समूहों के साथ यह संभव होगा, क्योंकि उनके पास अद्वितीय आईडी हैं। एक और तरीका यह हो सकता है कि प्रत्येक बनाए गए समूह को अलग माना जाए और उन सभी को उपयोगकर्ता को अलग इतिहास के रूप में दिखाया जाए। इस कदर:

26.05.2018 12:45 Tox Public Chat
26.05.2018 11:31 #toktok
26.05.2018 10:15 meeting
25.05.2018 08:10 meeting
24.05.2018 01:20 Tox Public Chat

यह उतना अच्छा नहीं है, लेकिन फिर भी प्रयोग करने योग्य है। कुछ लोग शायद इतिहास को इस तरह देखना भी पसंद करेंगे।