निर्बाध क्लाइंट-सर्वर इंटरैक्शन (WEB) सुनिश्चित करना

इस पोस्ट में मैं एक प्रोटोकॉल का वर्णन करने का प्रयास करूंगा जिसके साथ आप सर्वर से जुड़ने में समस्याओं के मामले में वेब एप्लिकेशन की विश्वसनीयता बढ़ा सकते हैं। मैं प्रौद्योगिकियों से अमूर्तता का वर्णन करने का प्रयास करूंगा, हालांकि, पाठ स्पष्टता के लिए यूआई पर सर्वर-साइड जावा कोड और जावास्क्रिप्ट / स्मार्टक्लाइंट का उदाहरण देगा और क्योंकि यह प्रोटोकॉल इन तकनीकों का उपयोग करके एक मौजूदा परियोजना के हिस्से के रूप में लागू किया गया था।

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

मैं काफी सरल प्रोटोकॉल के आधार पर इस तरह की समस्या के संभावित समाधानों में से एक को आपके ध्यान में लाना चाहता हूं।

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

* शब्द लेनदेन, इस संदर्भ में, एक परमाणु कार्य (या कार्यों का एक परमाणु सेट) का अर्थ है जो किसी सेवा के लिए अनुरोध करता है, निष्पादन का एक परिणाम प्राप्त करता है, और उपयोगकर्ता इंटरफ़ेस में परिवर्तन करता है। विफलता की स्थिति में, इसे भेजने के बार-बार प्रयास किए जाएंगे।

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

जिस परियोजना में मैं वर्तमान में भाग ले रहा हूं, उस पर अक्सर कनेक्शन रुकावट आती है, क्योंकि वे उपग्रह चैनल के माध्यम से समुद्र में जहाजों / प्लेटफार्मों से पहुंचते हैं। इसके अलावा, सिस्टम को लंबे समय तक विकसित किया गया है और इसमें समकालिक सेवाएं शामिल हैं जिन्हें लंबे समय तक निष्पादित किया जा सकता है, जिनके अनुरोधों को काट दिया जाता है जब प्रॉक्सी सर्वर समय पर पहुंचता है। बेशक, ऐसी सेवाएं वास्तुकला के दृष्टिकोण से सही नहीं हैं, लेकिन वहाँ क्या है। इस प्रोटोकॉल की क्षमताएं ऐसी सेवाओं को फिर से तैयार करने का विकल्प नहीं हो सकती हैं, लेकिन कम से कम ऊपर वर्णित समस्या का कार्य दौर है।

प्रोटोकॉल विवरण

ग्राहक भाग
- बैकएंड सेवा के प्रत्येक अनुरोध को लेनदेन में लपेटा जाता है
- एकल ब्राउज़र विंडो के भीतर प्रत्येक लेनदेन की विशेषता एक अद्वितीय लेनदेन पहचानकर्ता है। उदाहरण के लिए, एक नए लेनदेन की आईडी की गणना पिछले एक की आईडी को बढ़ाकर की जाएगी।
- प्रत्येक अनुरोध में एक अद्वितीय ब्राउज़र विंडो पहचानकर्ता जोड़ा जाता है। यह इस तथ्य के कारण है कि एक ही वेब सत्र के भीतर कई ब्राउज़र विंडो काम कर सकती हैं और लेन-देन पहचानकर्ता एकल ब्राउज़र विंडो के भीतर अद्वितीय हैं। विवरण नीचे वर्णित किया जाएगा।
- कनेक्शन समस्याओं (HTTP स्थिति प्रतिक्रिया कोड 4xx, 5xx या क्लाइंट टाइमआउट) के मामले में, अनुरोध और प्रतिक्रिया कनेक्शन त्रुटि हैंडलर को प्रेषित की जाती है।
- कनेक्शन त्रुटि हैंडलर उपयोगकर्ता इंटरफ़ेस को अवरुद्ध करता है और फिर से एक निश्चित समय अंतराल पर निष्पादन के लिए लेनदेन भेजता है, जो उपयोगकर्ता को एक संबंधित संदेश प्रदर्शित करता है।
- पुन: कनेक्ट होने पर, उपयोगकर्ता इंटरफ़ेस लॉक जारी किया जाता है और प्राप्त प्रतिक्रिया की सामान्य प्रसंस्करण जारी रहती है।

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

कुछ कार्यान्वयन विवरण का विवरण

क्लाइंट साइड जावास्क्रिप्ट, स्मार्टक्लाइंट 6.5
- SmartClient में, RPCManager.handleError विधि (प्रतिक्रिया, अनुरोध) का उपयोग करके सभी RPC त्रुटियों को डिफ़ॉल्ट रूप से पकड़ा जाता है

इसे फिर से परिभाषित करें और कनेक्शन समस्याओं के अवरोधन को इस प्रकार जोड़ें
..
if (response.status == isc.RPCResponse.STATUS_TRANSPORT_ERROR || response.status == isc.RPCResponse.STATUS_SERVER_TIMEOUT) {
isc.RPCManager.handleHttpError(response, request);
}
..

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

याद रखें कि आपको वेब सत्र के भीतर ब्राउज़र पहचानकर्ता की विशिष्टता सुनिश्चित करने की आवश्यकता है। ब्राउज़र पहचानकर्ता को स्थिर वैरिएबल RPCManager.clientId में परिभाषित किया गया है, जो कि जब क्लास को आरंभीकृत किया जाता है, तो इसे isc.timeStamp () टाइमस्टैम्प पर सेट किया जाएगा।
प्रत्येक अनुरोध में ClientId जोड़ने के लिए, हम उस विधि को फिर से परिभाषित करते हैं जिसके माध्यम से सभी RPC अनुरोध SmartClient पर जाते हैं
isc.RPCManager.addClassMethods({
..
sendRequestOriginal : RPCManager.sendRequest,
sendRequest : function (request) {
if (request.params == null) {
request.params = new Object();
}
request.params.clientId = RPCManager.clientId;
isc.RPCManager.sendRequestOriginal(request);
}
..

जावा बैकएंड, स्मार्टक्लाइंट डीएमआई
SmartClient में, क्लाइंट-सर्वर इंटरैक्शन उनके आंतरिक प्रोटोकॉल SmartClient DMI (डायरेक्ट मेथड इनवोकेशन) के अनुसार आयोजित किया जाता है। इसका सर्वर-साइड जावा कार्यान्वयन है।
यहां, प्रविष्टि बिंदु com.isomorphic.servlet.IDACall सर्वलेट है, जो विशिष्ट DMI सेवाओं के लिए अनुरोध भेजती है।
हमें इस वर्ग से विरासत में मिला है और web.xml में हमारे कार्यान्वयन को परिभाषित करता है
public void processRequest(HttpServletRequest request, HttpServletResponse response) ओवरराइड करने की public void processRequest(HttpServletRequest request, HttpServletResponse response)
यदि कोई सर्वलेट स्रोत कोड नहीं हैं, तो याद रखें कि आप हमेशा फ़ाइल वर्ग को हटा सकते हैं। हमें यह समझने की आवश्यकता होगी कि इस सर्वलेट में वास्तव में क्या हो रहा है और स्मार्टक्लाइंट डीएमआई के प्रसंस्करण में हमारी कार्यक्षमता को लागू करने के लिए।

एचटीटीपी अनुरोध से हमें क्लाइंट द्वारा प्रेषित ब्राउज़र पहचानकर्ता मिलता है
request.getParameter(CLIENT_ID)

हम सत्र वस्तु को request.getSession() माध्यम से प्राप्त करते हैं
याद रखें कि इस सत्र के ढांचे में सर्वर से अनुरोधों के कई प्रवाह के बीच साझा किए जाने के बाद से हमें सावधानी से काम करने की आवश्यकता है। जहां आवश्यक हो सत्र कॉल पर एक सिंक्रनाइज़ ब्लॉक में शामिल होना।

हम सेशन ऑब्जेक्ट को सेशन एट्रिब्यूट setAttribute()/getAttribute() विशेषता के रूप में सत्र ऑब्जेक्ट में संग्रहीत करते हैं

कैश संरचना इस प्रकार है:
Map<Long, Map<Long, CacheTransaction>> cache

कुंजी सत्र में ब्राउज़र आईडी है
मूल्य एक लेनदेन कार्ड है, जिसमें कुंजी लेन-देन आईडी है और मूल्य लेनदेन कार्यों के परिणामों के साथ एक वस्तु है।

हम इन कार्डों को Collections.synchronizedMap() माध्यम से थ्रेड-सुरक्षित तरीके से बनाते हैं। Collections.synchronizedMap()
केवल परमाणु कॉल यहां थ्रेड सुरक्षित होंगे, इसलिए हम जहां आवश्यक है, वहां सिंक्रनाइज़ किए गए ब्लॉक के बारे में भी नहीं भूलते हैं।

public class CacheTransaction {
private long transactionNum;
private long requestTimestamp;
private Map<Long, Object> responses;
..
यहां Map<Long, Object> responses उनके अनुरोधों के लिए सेवा प्रतिक्रियाओं का मानचित्र है।
यहां कुंजी अनुरोध हैश है और मूल्य प्रतिक्रिया का उद्देश्य है।

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