🤳🏿 🌅 🤾🏻 अस्थिर Google C2DM से कैसे निपटें 🥑 👴🏻 🐭

यह सिर्फ इतना हुआ कि काम पर मैं, समान विचारधारा वाले लोगों की एक छोटी टीम के साथ, विशेष रूप से, iPhone और Android के लिए स्मार्टफोन के लिए आवेदन लिखता हूं।

हमने iPhone के लिए विकास के साथ शुरू किया, जहां सब कुछ सुचारू रूप से काम करता था और जैसा कि यह होना चाहिए।
क्या काम किया? आवेदन का मुख्य कार्य एक अनुरोध भेजना था "आप कहां हैं?" - कुछ भी जटिल नहीं है। लेकिन मैं वास्तव में जितनी जल्दी हो सके इस अनुरोध को पतेदार तक पहुंचाना चाहूंगा, जबकि यह अभी भी प्रासंगिक है। यहां, iPhone के लिए विकसित होने का अनुभव होने पर, पाठक कहेंगे कि एपीएन सेवा है, और बिल्कुल सही होगी। यह हम थे जिन्होंने इसका उपयोग किया था, और दु: ख नहीं जानते थे, क्योंकि इन सूचनाओं को एक सेकंड से अधिक तेजी से वितरित किया गया था।

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

डेवलपर्स के सभी फोन पर सूचनाओं के वितरण में कोई समस्या नहीं थी। लेकिन नए उपयोगकर्ताओं को तुरंत एक बड़ी समस्या का सामना करना पड़ा - सूचनाओं के लिए डिलीवरी का समय गारंटी नहीं था, और उनमें से कुछ कुछ घंटों में पहुंच गए। और उसी डिवाइस पर, वे सेकंड में पहुंच गए।

इस समस्या पर शोध करने के दौरान, मुझे Google की ओर से इन सूचनाओं के संचालन के कई अजीब लक्षण आए।

अंधाधुंध रूप से सर्वर के साथ स्मार्टफोन के कार्यान्वित निम्न-स्तरीय इंटरैक्शन में रुचि रखने वाले लोग इन पूर्वापेक्षाओं को छोड़ सकते हैं और अनुभाग 4 पर जा सकते हैं। Google C2DM का विकल्प, लेकिन प्रतिस्थापन नहीं। "

1. सूचनाओं के उपयोग की योजना

सबसे पहले, एक किन्नर (पद स्पष्टता के लिए चुना जाता है, और GOST y के अनुसार नहीं):
स्मार्टफोन-सर्वर-सी 2 डीएम नेटवर्क आरेख

समस्या का अध्ययन करने के लिए, आपको यह समझने की आवश्यकता है कि यौगिक 1, 2 और 3 कैसे काम करते हैं।

यह हमारा खुला HTTP कनेक्शन है जो अनुरोध भेजता है। एप्लिकेशन को सर्वर से केवल 200 ओके की उम्मीद है और बाकी महत्वपूर्ण नहीं है। बोतल का एक विस्तृत हिस्सा है - अब तक कुछ उपयोगकर्ता हैं, और वे कुछ अनुरोध भेजते हैं (सक्रिय कार्य के दौरान 60-100 संदेश / एस)।
हमारा सर्वर HTTP से Google के सर्वर तक इस कनेक्शन को खोलता है। इस मामले में, आपको लगातार 2 कनेक्शन बनाने होंगे: पहले अनुशंसित विधि द्वारा प्राधिकरण - क्लाइंटलॉगिन, फिर android.clients.google.com/c2dm/send पर एक अनुरोध। पहली चीज़ जो उन्होंने एक समस्या की तलाश में शुरू की थी, वह यहाँ थी।
अंत में, यह कनेक्शन Google को Android स्मार्टफ़ोन के साथ रखता है।

2. हम C2DM के अनुरोध के साथ समस्याओं की तलाश कर रहे हैं

चूंकि मैं मुख्य रूप से सर्वर साइड विकसित करता हूं, इसलिए कनेक्शन नंबर 2 में संभावित समस्याओं के लिए पहले पत्थर ने मुझ में उड़ान भरी। क्या किया गया है?

मेरी विनम्र राय में, आवेदन में C2DM को कैसे जोड़ा जाए, इसका सबसे अच्छा विवरण हैब्रेटोपिक में। हम क्लाउड टू डिवाइस मैसेजिंग (C2DM) के लिए समर्थन के साथ एक Android एप्लिकेशन लिख रहे हैं

यह कनेक्शन स्वयं इस लेख की सिफारिशों के अनुसार लागू किया गया है।

कभी-कभी Google सर्वर से कनेक्ट होने के दौरान, कनेक्शन समयबद्ध हो गया, जिसने मुझे हमारे एक साथ कनेक्शन की संख्या को सीमित करने के विचार के लिए प्रेरित किया। सोचा गलत हो सकता है, लेकिन लागू समाधान उपयोगी साबित हुआ।
सर्वर साइड जावा में लिखा गया है और जेटी के साथ एक अलग JAR के रूप में चलता है। स्प्रिंग फ्रेमवर्क स्थापित करने और चलाने के लिए जिम्मेदार है, जिसका अर्थ है कि मैं C2DM सर्वर के साथ बातचीत को काफी दर्द रहित रूप से पुन: कॉन्फ़िगर करने में सक्षम था।

चरण 1

क्वेरी निष्पादन के लिए अतुल्यकालिक जोड़ें।

public class C2DMServer implements IPushNotificator, IPushChecker { ... @Override @Async //     public void sendData(String deviceId, String c2dmID, String jsonObject) { ... } }

इस कदम ने एक और सुधार दिया - अनुरोध करने वाले ग्राहक की 200 ओके प्रतिक्रिया अब बहुत तेजी से आती है, क्योंकि स्ट्रीम Google अधिसूचना सर्वर से प्रतिक्रिया की प्रतीक्षा नहीं करती है।

चरण 2

Google के समवर्ती अनुरोधों की संख्या को सीमित करने के लिए कॉन्फ़िगर करें।
गुणांक के बहुत सारे परीक्षण और चयन थे, और परिणाम इस तरह के स्प्रिंग सेटिंग में हुआ।

 <task:annotation-driven executor="asyncExecutor" /> <task:executor id="asyncExecutor" pool-size="15" queue-capacity="300" rejection-policy="CALLER_RUNS" />

यदि पूल-आकार 15 से अधिक पर सेट है, तो एक साथ कनेक्शन की यह संख्या सभी प्रकार की नेटवर्क त्रुटियों की ओर ले जाती है।

परिणाम

क्या प्रसन्न हुआ : Google सर्वर से जुड़ने में कोई और त्रुटि नहीं थी।
क्या परेशान : वितरण की गति की समस्या बनी हुई है, जिसका अर्थ है कि हम आगे बढ़ रहे हैं।

3. एंड्रॉइड के साथ Google के काम का अन्वेषण करें

एंड्रॉइड पर इंस्टॉल करने के बाद, कोई भी एप्लिकेशन एक विशेष सेवा से एक पहचानकर्ता से अनुरोध कर सकता है जिसके साथ सूचनाएं भेजनी हैं।

यह बेस क्लास C2DMBaseReceiver से विरासत में मिला है।
आप एक ही निवास स्थान में इस तरह की विरासत का एक उदाहरण देख सकते हैं। हम क्लाउड टू डिवाइस मैसेजिंग (C2DM) के समर्थन के साथ एक एंड्रॉइड एप्लिकेशन लिख रहे हैं । यहाँ मेरे लिए एक संशोधित कार्यान्वयन है:

 import com.google.android.c2dm.C2DMBaseReceiver; public class C2DMReceiver extends C2DMBaseReceiver { private static final String DATA = "data"; public C2DMReceiver() { super(Settings.C2DM_ACCOUNT); } @Override public void onDestroy() { super.onDestroy(); } @Override public void onError(Context context, String errorId) { Settings.Init(context, false); Settings.updateC2DM(null); } @Override protected void onMessage(Context context, Intent receiveIntent) { Settings.Init(context, false); String data = receiveIntent.getStringExtra(DATA); JSONUtils.processJSON(context, data); } @Override public void onRegistered(Context context, String registrationId) { Settings.Init(context, false); if (!registrationId.equals(Settings.getC2dm_id())) Settings.updateC2DM(registrationId); } @Override public void onUnregistered(Context context) { } }

यहाँ सेटिंग्स एक सहायक वर्ग है जिसमें स्टेटिक फ़ील्ड्स का एक गुच्छा और एप्लीकेशन स्टेट स्टोर करने की विधियाँ हैं। JSONUtils एक अन्य सहायक वर्ग है जो JSON को पार्स करता है और सभी डेटा को सेटिंग्स में संग्रहीत करता है।

यह समझना महत्वपूर्ण है कि पहचानकर्ता की प्राप्ति का क्षण परिभाषित नहीं है। वास्तव में, इस वर्ग के साथ हम C2DM पहचानकर्ता प्राप्त करने की घटना पर लटका रहे हैं, और सिद्धांत रूप में, जब यह ट्रिगर हो जाता है, तो हमें तुरंत पहचानकर्ता को सर्वर में स्थानांतरित करना चाहिए।
ऐसे पहचानकर्ता के एक उदाहरण: «APA91bF8hral5wCq_E7HPD1wq29aSIEYyY2g_P4BOue_CaBTJvTHKFPplmp2MHxFgn3c1ysNjTHyXmsp8OejRSc809ZiOYqNcXoJWiWfvarCayT6ar3RyZwRRV0CrgQNaPjLxTrYqXXcQfcxjB07xmjeNtUzc6UlGQ»।

उसके बाद, इस पहचानकर्ता के साथ C2DM सर्वर को कोई भी संदेश वांछित डिवाइस और एप्लिकेशन तक पहुंचाया जाना चाहिए।

आइए देखें कि इन संदेशों को कैसे वितरित किया जाता है

C2DM-GTalk एप्लिकेशन इंटरएक्शन आरेख

सभी के केंद्र में क्लाउड टू डिवाइस मैसेजिंग है।
दिलचस्प बात यह है कि समस्याग्रस्त उपकरणों पर, यह सेवा कभी-कभी मेमोरी से अनलोड होती थी। इसका मतलब है कि यह कोई ओएस लॉक नहीं लेता है और एंड्रॉइड को संसाधनों की आवश्यकता होने पर अच्छी तरह से बंद कर सकता है। यह सेवा Google मैसेजिंग सेवा का उपयोग करती है, जिस पर एक्सचेंज प्रोटोकॉल के मूल के रूप में GTalk भी निर्भर करता है। इसका कारण यह है कि X2P प्रोटोकॉल में C2DM प्रोटोकॉल एनकैप्सुलेटेड है जिस पर GTalk एक्सचेंज करता है। इस चैनल पर, हर 300 सेकंड में, C2DM सेवा Google सर्वर को पिंग भेजती है और यह सुनिश्चित करने के लिए इंतजार करती है कि कनेक्शन क्रम में है। अधिक जानकारी के लिए, इस वीडियो में स्रोत देखें।
सेवाओं के साथ, ज़ाहिर है, सब कुछ इतना दुखी नहीं है। अधिसूचना सेवा तब ठीक हो सकती है जब नेटवर्क की स्थिति बदलती है और जब स्क्रीन चालू होती है, हालांकि हमेशा नहीं।
अपने कनेक्शन की स्थिति देखने के लिए, आप *#*#8255#*#* डायल कर सकते हैं और खुलने वाले GTalk Service Monitor में देखें कि Google मैसेजिंग के माध्यम से कौन सा एप्लिकेशन एक्सचेंज कर रहा था।

इसलिए, समस्या का एक हिस्सा पहचान लिया गया था, लेकिन इसका कोई समाधान नहीं था।
बिल्कुल हिस्सा क्यों? क्योंकि सूचनाएं रनिंग सर्विसेज के साथ भी नहीं पहुंचती थीं। कभी-कभी कुछ समय (20-40 मिनट) के बाद सूचनाओं की लहरें आती थीं, सभी उपकरणों को एक ही समय में सूचनाएं प्राप्त होती थीं, हालांकि उन्हें अलग-अलग समय पर भेजा जाता था।

नतीजतन, सोचने के बाद, प्रलेखन और कई मंचों और क्यू एंड ए को पढ़ना, सभी एक बात पर सहमत हुए - हम एक वैकल्पिक अधिसूचना चैनल करेंगे।

4. Google C2DM विकल्प , लेकिन प्रतिस्थापन नहीं

मुख्य सवाल: एक स्थिर सर्वर-क्लाइंट चैनल का निर्माण कैसे करें?
एक पक्ष का सवाल: इस चैनल के साथ पूरे उपयोगकर्ता की बैटरी कैसे नहीं खाएं?

प्रेरणा का स्रोत http://code.google.com/p/android-random/ से उदाहरण थे।
विशेष रूप से, उदाहरण KeepAliveService है ।

पहला विचार एक ललाट समाधान है: प्रत्येक एन सेकंड के बाद, सर्वर से कनेक्शन खोलें और सूचनाओं के लिए जांच करें।
"सर्वर को अक्सर क्वेरी" करने के लिए इस हेड-ऑन समाधान के बजाय, लेखक एक अधिक उचित विकल्प का प्रस्ताव करते हैं, हालांकि यह एक तरह का हैक जैसा दिखता है।

प्रस्तावित समाधान के चिप्स:

सर्वर से कनेक्शन को लगातार रखा जाना चाहिए, और अंतराल पर पुन: कनेक्ट नहीं किया जाना चाहिए;
प्रत्येक n सेकंड, जहां n> 60, कुछ को भेजकर कनेक्शन की स्थिति की जांच करें और टूट जाने पर ही पुन: कनेक्ट करें;
सर्वर कनेक्शन पर एक अवरुद्ध पढ़ने का उपयोग करें।

मैंने क्लाइंट अधिसूचना सर्वर के साथ काम करने के लिए विभिन्न विकल्पों का परीक्षण किया।
2 ग्राहक लिखे गए थे:

मैंने इसे हर एन सेकंड में एक बार खोला और पढ़ा कि क्या कुछ दिखाई दिया था। यह n था कि परीक्षण में विविध था
मैंने एक स्थायी कनेक्शन खोला और इसे हर 60 सेकंड में जांचा। जीवन के समय कितने अलग हैं, यह जानने के लिए डिवाइस विविध हैं।

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

	ग्राहक 1				ग्राहक २
युक्ति	इच्छा	इच्छा	इच्छा	इच्छा	इच्छा	जंगल की आग	इच्छा s
परीक्षण अवधि (मिनट)	540	1273	845	962	1117	1180	1121
चार्ज यूनिट्स	82	87	31	9	39	80	49
सेकेंड में रखें	10	30	60	60	60	60	60
इंटरनेट कनेक्शन	3 जी	3 जी	3 जी	वाईफ़ाई	3 जी	3 जी	3 जी
परिकलित निर्वहन दर (e.z./h)	10	4.28	2.22	0.56	2.22	4.28	3

कई परिणाम तुरंत स्पष्ट हैं:

हालांकि कनेक्शन को फिर से खोलना, कम से कम इसे खुला रखना - यह बैटरी के दृष्टिकोण से कोई फर्क नहीं पड़ता।
3 जी वाईफाई की तुलना में बैटरी को कई गुना तेज जला देता है।
इष्टतम मतदान का समय 60 सेकंड है।

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

टीसीपी कनेक्शन की आमद को झेलने के लिए, मैंने निम्नलिखित आर्किटेक्चर का निर्माण किया।
खुद की अधिसूचना सर्वर

अधिसूचना सर्वर में दो घटक होते हैं:

राउटर - कनेक्टेड डिवाइस को पंजीकृत करता है और इसे सर्वर का पता और पोर्ट देता है जिसके साथ जुड़ा रहता है। इसके अलावा, वह वांछित अधिसूचना सर्वर को सूचनाएं भेजने के लिए सभी अनुरोधों को रूट करता है।
अधिसूचना सर्वर खुद - कनेक्शन रखता है, राउटर को डिवाइस से रखने की सफल रसीद के बारे में सूचित करता है और यदि राउटर इसे कहते हैं तो एक अधिसूचना भेजता है।

क्लाइंट के साथ सभी इंटरैक्शन शुद्ध टीसीपी पर चलते हैं। अधिसूचना स्वयं किसी भी आकार और सामग्री की हो सकती है, लेकिन मेरे आवेदन में लोड को कम करने के लिए, मैं बिल्कुल एक बाइट "1" भेजता हूं।
सर्वर घटकों के बीच, स्प्रिंग रीमोटिंग का उपयोग करके, आरएमआई कनेक्शन बढ़ते हैं।

अब चरणों में क्लाइंट साइड लॉजिक देखते हैं।

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

अलार्म मैनजर के साथ काम करना बहुत सरल है।

 //  ,       Intent i = new Intent(this, NotificationService.class).setAction(ACTION_KEEPALIVE); PendingIntent pi = PendingIntent.getService(this, 0, i, 0); //      AlarmManager- AlarmManager alarmMgr = (AlarmManager) getSystemService(ALARM_SERVICE); alarmMgr.setRepeating(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + KEEP_ALIVE_INTERVAL, KEEP_ALIVE_INTERVAL, pi);

प्रलेखन में अधिक जानकारी।

मेरे कार्यान्वयन के परिणाम या समस्याएं या पूरी तरह से C2DM को छोड़ना असंभव क्यों है

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

5. निष्कर्ष

"किसी भी स्वाभिमानी स्मार्टफोन प्रोग्रामर को अधिसूचना सेवा के अपने कार्यान्वयन को लिखना चाहिए" - यह है कि उन्होंने मेरे काम के परिणाम का मजाक उड़ाया।
लेकिन मजाक के बावजूद, ऊपर वर्णित अधिसूचना सेवा एक ही गति से काम करती है और लगभग ऐप्पल के समान स्थिरता है, जो आनन्दित नहीं कर सकती है, और डिवाइस का जीवन समय, जिसे डेवलपर्स बहुत चिंता करते हैं, बहुत कम नहीं है।

6. उपयोगी लिंक

अच्छे अधिसूचना वितरण को कैसे लागू किया जाए, इस पर विचार
Google C2DM कनेक्टिविटी दस्तावेज़
Habratopik "हम क्लाउड टू डिवाइस मैसेजिंग (C2DM) के लिए समर्थन के साथ Android के लिए एक आवेदन लिख रहे हैं"
C2DM और अन्य की गति के बारे में शिकायतें - मुझे उम्मीद है कि एक दिन उनका जवाब “हुर्रे! सब कुछ काम किया! ”

अस्थिर Google C2DM से कैसे निपटें