जब अनुरोध सर्वर पर भेजा जाता है और प्रतिक्रिया इंटरनेट कनेक्टिविटी के खो जाने के इंतजार में क्या करना है?

Question

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

Comments

हम कितने डेटा की बात कर रहे हैं? गीगाबाइट?

— डैनियल हॉलिनरेके

लगभग 7-8 एमबी के आसपास नहीं है, लेकिन सर्वर प्रतिक्रिया समय बहुत लंबा है, और फोन से अपलोड करने की दर लगभग 128 केबी / एस है। मैं डेटा साइज़ की नहीं बल्कि कनेक्शन की समस्या की बात कर रहा हूँ।

— मयंक_ड्रॉइड

Answer 1

यह अतुल्यकालिक लेनदेन के साथ एक काफी सामान्य समस्या है, और कई हिस्सों में गिरती है।

1. दोनों पक्षों को कैसे पता चलेगा कि लेनदेन अनुरोध सफलतापूर्वक प्राप्त हुआ है?
2. आप एक लेन-देन अनुरोध को कैसे पुन: भेजें जो क्लाइंट का मानना ​​है कि ठीक से प्राप्त नहीं हुआ है?
3. जब सर्वर सफलतापूर्वक पहला अनुरोध प्राप्त करता है तो सर्वर क्लाइंट से दोहराए जाने वाले अनुरोधों का पता कैसे लगाता है?
4. ग्राहक को यह कैसे पता चलता है कि लेनदेन के परिणाम कहां से प्राप्त होंगे?

HTTP के बारे में बड़ी बात यह है कि इन सभी मुद्दों को हल करने के लिए यह काफी आसान है।

इस तरह एक URL संरचना की कल्पना करें:

POST http://my.server.com/application/engine/queue 
GET   http://my.server.com/application/engine/results?jobid=43425

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

क्लाइंट को परिणाम URL से अनुरोध के परिणाम मिलते हैं। इस कॉल को परिणाम प्राप्त करने के लिए आवश्यकतानुसार दोहराया जा सकता है। यदि परिणाम उपलब्ध होने से पहले इसका कॉल किया जाता है, तो प्रतिक्रिया एक NO-CONTENT प्रतिक्रिया हो सकती है ताकि क्लाइंट को पता चले कि सर्वर जॉब आईडी को पहचानता है, लेकिन अभी तक सामग्री नहीं है। अगर जॉब आईडी को मान्यता नहीं है, तो NOT-FOUND उपयुक्त प्रतिक्रिया है।

अंतिम परिणाम यह है कि क्लाइंट हमेशा एक समझदार कार्रवाई कर सकता है जब नेटवर्क खो जाता है और पुनर्प्राप्त होता है, और इसी तरह सर्वर हमेशा क्लाइंट से अनुरोधों को समझदारी से संसाधित कर सकता है।

Comments

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

— साइमन रिक्टर

यह उस स्थिति का प्रबंधन करेगा जहां अनुरोध के प्रसारण के दौरान कनेक्शन खो गया था। जैसा कि पूछा गया है कि डेटा भेजे जाने के बाद कनेक्शन खो जाने के बारे में बात कर रहा है, लेकिन प्रसंस्करण से पहले अनुरोध पूरा हो गया है।

— माइकल शॉ

वह भी संभाला हुआ। "कमिट" लेन-देन छोटा है और लेनदेन आईडी का उपयोग करता है, इसलिए इसे डेटा को फिर से स्वीकार किए बिना सस्ते में फिर से जारी किया जा सकता है, और सर्वर या तो प्रसंस्करण शुरू कर सकता है, या पहले के आह्वान से परिणाम वापस कर सकता है। यह आपके सुझाव के समान है; अंतर यह है कि मेरे पास नौकरी आईडी बनाने के लिए एक अलग अनुरोध है, इसलिए मेरे पास एक अतिरिक्त सिंक्रनाइज़ेशन बिंदु है, इसलिए ग्राहक को पता चल सकता है कि क्या नौकरी पहले से ही पूर्ण अनुरोध को पुनः प्राप्त किए बिना मौजूद है या नहीं।

— साइमन रिक्टर

हाँ, यह समझ में आता है।

— माइकल शॉ

इस तरह, यदि लेनदेन में सर्वर पर आंशिक डेटा होता है, तो मुझे पता है कि एक ग्राहक मौजूद है जो इस आईडी को जानता है और लेनदेन को पूरा करने की कोशिश करता है, इसलिए मैं आंशिक स्थिति रख सकता हूं और ट्रांसमिशन आधे रास्ते को फिर से शुरू करने, बैंडविड्थ आवश्यकताओं को कम करने और हटाने की पेशकश कर सकता हूं डुप्लिकेट खोजने के लिए अनुरोध सामग्री की तुलना करने की आवश्यकता है।

— साइमन रिक्टर

Answer 2

यह प्रोटोकॉल संचार की मूल बातें के अंतर्गत आता है। एंड्रॉइड क्लाइंट द्वारा लेनदेन का अनुरोध किया गया है, और सर्वर को लेनदेन करना है। यदि लेन-देन Android क्लाइंट पावती पर निर्भर है, तो इसे ACK / NAK संचार कहेंगे।

ACK (पावती) और NAK (नकारात्मक-पावती) का उपयोग दूसरे पक्ष को अनुरोध का परिणाम बताने के लिए किया जाता है।

आप जिस चीज के बारे में पूछ रहे हैं , वह क्लाइंट और सर्वर के बीच एक प्रकार का हैंडशेकिंग एक्सचेंज है, और इसे बेसिक ACK /AK एक्सचेंज के साथ किया जा सकता है।

यहां दो तरह से पावती के साथ फ़ाइल अपलोड करने का एक उदाहरण दिया गया है।

Android -> upload files -> Server
Android <- ACK #id <- Server
Android -> ACK #id -> Server

उपरोक्त उदाहरण में मैंने #idलेनदेन के लिए एक विशिष्ट पहचानकर्ता जोड़ा है । सर्वर को फाइलें प्राप्त होनी चाहिए, एक लेनदेन रिकॉर्ड बनाना चाहिए और इसे प्रतिक्रिया के रूप में एंड्रॉइड पर वापस भेजना चाहिए। एंड्रॉइड को तब उस लेनदेन की पावती के साथ पालन करना चाहिए (या वैकल्पिक रूप से अस्वीकृति के लिए NAK)।

हैंडशेकिंग के दौरान एंड्रॉइड डिस्कनेक्ट करने का एक उदाहरण यहां दिया गया है।

Android -> upload files -> Server
Android <- ACK #id <- Server
/** no ACK response **/

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

सर्वर मान सकता है कि चूंकि डिवाइस ने ACK के साथ कोई प्रतिक्रिया नहीं दी है। एंड्रॉइड डिवाइस ने अपडेट को अपलोड करने में सफल होने के लिए आंतरिक स्थिति को अपडेट नहीं किया था। मैं लेन-देन को छोड़ दूंगा और डिवाइस को भविष्य में इसे दोहराने की अनुमति दूंगा।