डिवाइस पर एक्सएमपीपी पर खोए गए संदेश

Question

मैं एक्सएमपीपी पर एक टर्न बेस गेम विकसित करने की कोशिश कर रहा हूं। (मल्टीप्लार्टर गेम के लिए मुझे मिला एकमात्र समाधान)। मैं बिना किसी समस्या के संदेश भेज सकता हूं। यदि अन्य उपयोगकर्ता ऑनलाइन नहीं है, तो सर्वर (ओपनफायर) इसे बाद में वितरित करने के लिए सहेजता है।

समस्या तब होती है जब कोई डिवाइस नेटवर्क बदलता है (3 जी से वाईफाई में बदल जाता है, 3 जी आईपी बदलता है ...) या डिवाइस नेटवर्क खो गया (3 जी, वाईफ़ाई या खोया कनेक्शन बंद करें)। सर्वर सोचता है कि डिवाइस ऑनलाइन है और संदेश भेजता है लेकिन यह (obviusly) कभी नहीं पहुंचता है, इसलिए पैकेट खो जाता है।

मुझे एक समाधान पता है। मेरे गेम प्रोटोकॉल पर एसीके लागू करें, लेकिन मुझे इस विचार को ज्यादा पसंद नहीं है। क्या आपके पास कोई अन्य सुझाव है? मुझे लगता है कि यह एक सर्वर समस्या है। क्या आप जानते हैं कि एक और सर्वर चुड़ैल टीसीपी या एसीके लागू करता है?

धन्यवाद !!

संपादित करें: मैं ऐसा करता हूं: सर्वर से डिवाइस कनेक्ट करें। मैं डिवाइस पर 3 जी और वाईफाई कनेक्टिविटी बंद कर देता हूं। एंड्रॉइड और सर्वर अभी भी सोच रहा है कि कनेक्शन जिंदा है।

http://issues.igniterealtime.org/browse/SMACK-331

पीडी: मैं ओपनफींट करने के लिए कह वे एपीआई मल्टीप्लेयर के लिए, लेकिन वे मेरे asnwer नहीं था ...

Answer 1

कुछ शर्तें टीसीपी/आईपी विश्वसनीय नहीं है के तहत। यही कारण है कि एक्सएमपीपी में एसीके, संदेश रसीदें, आईक्यू या अन्य एक्सटेंशन इस समस्या को हल कर सकते हैं।

मैंने कई वर्षों में मोबाइल प्रोग्रामिंग किया है, अक्सर ओपनफायर के साथ भी। लेकिन मैंने खोए संदेशों को नहीं देखा है। तो मुझे लगता है कि आप जिस लाइब्रेरी का उपयोग कर रहे हैं उसमें लाइब्रेरी या ओपनफायर संस्करण का उपयोग करने में कोई समस्या है।

इसके बजाय कच्चे सॉकेट का उपयोग कर आप भी बकवास उपयोग कर सकते हैं की :
http://xmpp.org/extensions/xep-0124.html
बकवास धूमकेतु की तरह WebRequests पर आधारित है और वातावरण जहां आप कनेक्शन स्विच या ढीला अक्सर में बहुत अच्छी तरह से काम करता है। जब तक आपका नेटवर्क वापस नहीं आ जाता है तब तक यह कनेक्शन को जीवित रख सकता है और परिणामस्वरूप एक या अधिक अनुरोध पंक्ति में विफल होने पर कनेक्शन ड्रॉप नहीं होता है।

Answer 2

हालांकि बीओएसएच इस मामले में काम करेगा, दूसरा विकल्प XEP-0198 है: स्ट्रीम प्रबंधन। यह आपको पूरी तरह से जुड़े सॉकेट के साथ-साथ त्वरित रीकनेक्ट, पॉजिटिव एकिंग और क्यूइंग के साथ-साथ दोनों दिशाओं में अनचाहे या डिस्कनेक्ट होने के साथ-साथ पूरी तरह से जुड़े सॉकेट के सभी प्रदर्शन करने की अनुमति देगा।

Answer 3

मैं भी इस मुद्दे पर आया और इसे हल करने के लिए एक उचित तरीका जानने का प्रयास कर रहा था।

मेरे लिए समस्या यह है कि मैंने ऑफ़लाइन संदेश नीति को "हमेशा स्टोर" पर सेट किया है और इस प्रकार XEP-0184 वास्तव में यह निर्धारित करने में सहायता नहीं करता है कि कोई संदेश अपने रिसीवर को वितरित नहीं किया जा रहा है या नहीं।

इस परिदृश्य प्रदान करना: - एक एक संदेश भेजता है बी, जबकि बी के कनेक्शन सिर्फ खो गया - - संदेश गिरा दिया गया और एक अधिसूचित नहीं किया गया है - इस मामले में मैं 2 उपयोगकर्ताओं, चैटिंग उन्हें एक फोन और बी है ए को पता नहीं है कि संदेश गिरा दिया गया है, यह सिर्फ यह मान लेगा कि संदेश सर्वर पर पहुंचाया गया है, सर्वर अंततः इसे बी पर वितरित करेगा - बी हमेशा के लिए संदेश खो देता है

तो मैं अस्थायी रूप से अस्थायी रूप से एक काम में डालता हूं इसके लिए ... मैं उन सभी संदेशों को संग्रहीत करता हूं जो वितरित नहीं होते हैं (यानीसंदेश वितरण रसीद प्राप्त नहीं हुई है), समय-समय पर (कहें, 6 मिनट - यह वह समय है जब उन मृत कनेक्शनों को मिटा दिया गया था) यह देखने के लिए कतार के प्रत्येक संदेश की जांच करें कि इच्छित प्राप्तकर्ता "ऑनलाइन" है और रसीद अभी भी प्राप्त नहीं हुआ ... यदि यह मामला है, तो मैं उस संदेश को "असफल डिलीवरी" के रूप में चिह्नित करता हूं

यह ठीक करने का एक बहुत ही भयानक तरीका है (कृपया सलाह दें कि क्या आपके पास ऐसा करने का बेहतर तरीका है)। मुझे लगता है कि सर्वर को ऐसा करने के लिए सबसे अच्छी बात यह है कि: यदि संदेश वितरित करने में विफल रहा है और ऑफ़लाइन संदेश नीति "हमेशा स्टोर करें" है, तो हम इसे देरी डिलीवरी के लिए "ऑफ़लाइन" पर संग्रहीत करते हैं।

Answer 4

यह एक पुराना है, लेकिन मैं हाल ही में इस तरह के एक मुद्दे को हल कर रहा था। जब मैंने कनेक्शन बनाते समय एक्सएमपीपी संसाधन (पूर्ण जेआईडी का अंतिम भाग) सेट किया, तो यह मेरी मदद की। अन्यथा यह प्रत्येक पुन: कनेक्ट पर यादृच्छिक उत्पन्न होगा - और यह पूर्ण जेआईडी को बदल देता है।