प्रोटोकॉल के लिए एक विश्वसनीय HTTP गेटवे कैसे डिज़ाइन किया जाए जिसके लिए निरंतर कनेक्शन की आवश्यकता होती है?

Question

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

मैं यह पूछ रहा हूं क्योंकि मैं आरपीसी-आईएसएच परिणाम के साथ समाप्त नहीं होना चाहता जो "रीस्टफुल" दिखता है।

समस्या विशिष्ट संदर्भ: मैं तात्कालिक नोड्स और घड़ियों का समर्थन करने के लिए मौजूदा चिड़ियाघर आरईएसटी गेटवे में सुधार करना चाहता हूं। क्लाइंट सर्वर से कनेक्ट होने पर एक क्षणिक नोड मौजूद है।

धन्यवाद।

Answer 1

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

पूर्व।

अनुरोध: प्राप्त/चिड़ियाघर संचालक/znode/अल्पकालिक/foo प्रतिक्रिया: 1234-1234-1234-1234

अनुरोध: प्राप्त/चिड़ियाघर संचालक/स्थिति/1234-1234-1234-1234 प्रतिक्रिया: श्रमजीवी (या अनुपलब्ध या अवरुद्ध या NOTREADY या विफल ...)

अनुरोध: प्राप्त/चिड़ियाघर संचालक/स्थिति/1234-1234-1234-1234 प्रतिक्रिया: अधिग्रहणः (या उपलब्ध या ठीक या सफलता या कुछ मूल्य (रों) ...)

अनुरोध: प्राप्त करें/ज़ूकीपर/स्वीकृति/1234-1234-1234-1234 प्रतिक्रिया: ठीक (या अज्ञात TICKET, आदि)

दिलचस्प प्रबंधन क्षमता संदेशों:

अनुरोध: प्राप्त/चिड़ियाघर संचालक/सत्र (या/टिकट) प्रतिक्रिया: [1234, 5668, ...]

अनुरोध : GET/zookeeper/kill/ प्रतिक्रिया: ठीक है (या अज्ञात या FAILED ...)

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

उम्मीद है कि इससे मदद मिलती है।