मैं कहूंगा कि यह बाकी स्थापत्य शैली के साथ अच्छी तरह से उड़ान भरने नहीं करता है (जिसका मुख्य कारण बाकी राज्यविहीन क्लाइंट सर्वर बातचीत के लिए यह रोकें)। हालांकि, वेब उन समाधानों के साथ प्रचुर मात्रा में है जो वेब की भावना में नहीं होने के बावजूद लंबे मतदान करते हैं, और यह कम या ज्यादा काम करता है।
पहले, वास्तुकला पर एक नोट: लागू करने बाकी भीतर पब/उप केवल अर्थ यह है कि प्रकाशक एक सूची है जो फिर ग्राहकों के लिए उपलब्ध कराया गया है करने के लिए आइटम कहते हैं। सब्सक्राइबर्स सूची में मतदान करते हैं। संदेश आदेश और (एक रूप) गारंटीकृत डिलीवरी को बनाए रखने के दौरान, एक बार और केवल एक बार सुनिश्चित करने के लिए इसे तैयार करने के तरीके हैं, हालांकि एसिंक्रोनस। यह वास्तव में अच्छी तरह से तराजू, और वास्तव में लचीला है।
मेरी सलाह का पहला टुकड़ा यह वैकल्पिक बनाने के लिए इतना है कि ग्राहकों कि लंबे समय से मतदान नहीं कर सकता है (या नहीं करना चाहते हैं) ऐसा कर सकते हैं हो सकता है,। मैं अब तक यह कहूंगा कि यदि एक सामान्य क्लाइंट (Google की तरह) डिफ़ॉल्ट होगा तो लंबे मतदान करने के लिए नहीं होगा, और सर्वर आपके क्लाइंट के बीच विशेष साझा समझ के माध्यम से लंबे मतदान को लाता है और सर्वर। वह साझा समझ एक कस्टम मीडिया प्रकार या एक कस्टम लिंक संबंध हो सकता है, या यहां तक कि एक कस्टम HTTP शीर्षलेख भी हो सकता है जो सामान्य ग्राहकों को नहीं पता होगा। आपके लंबे मतदान का समर्थन करने वाले ग्राहक को लंबे मतदान की क्षमताओं की खोज करेंगे, और लंबे समय तक मतदान विफल होने पर नियमित मतदान पर वापस आना आवश्यक है (उदाहरण के लिए मध्यस्थ इसे किसी भी तरह से अवरुद्ध करता है)।
और बजाय HTTP के शीर्ष पर ऐसा करने की कोशिश की, मैं इस के लिए एक गैर- HTTP सॉकेट का उपयोग कर, HTTP के इरादे का उल्लंघन नहीं करने के लिए और प्रभावी रूप से एक परिवहन प्रोटोकॉल के रूप में HTTP का उपयोग सुझाव है। धूमकेतु देखें।
मेरी अन्य सलाह का सवाल यह पूछना होगा कि आपके ग्राहकों को "वास्तविक समय" कैसे होना है। यदि कुछ सेकंड विलंबता स्वीकार्य है तो आप नियमित मतदान के उपयोग से इसे सुलझाने की कैश करने योग्य प्रकृति के कारण, नियमित रूप से बड़ी संख्या में ग्राहकों के लिए नियमित मतदान के साथ एक बड़ा सौदा कर सकते हैं।
विस्तृत प्रतिक्रिया के लिए धन्यवाद। मेरे साथ एकमात्र मुद्दा यह है कि पब/उप अपनी प्रकृति से असीमित है और मतदान के किसी भी रूप में इस बिंदु को याद किया जा रहा है कि घटनाओं को अतुल्यकालिक रूप से धक्का दिया जाना चाहिए, खींच नहीं लिया जाना चाहिए। प्रतिक्रिया वास्तविक समय होनी चाहिए क्योंकि आने वाली कॉल का जवाब देने के लिए हमें एक्सटेंशन पॉप अप करने की आवश्यकता होती है। एक व्यस्त स्थापना पर, घटनाएं हर दूसरे या यहां तक कि तेज हो सकती हैं। मैं अनुमान लगा रहा हूं कि सर्वर एक टोकन या टाइमस्टैम्प वापस करेगा जो अगले अनुरोध में उपयोग किया जा सकता है ताकि यह सुनिश्चित किया जा सके कि कोई ईवेंट मिस नहीं है। –
हाँ। सोचें कि ट्विटर कर्सर आधारित पेजिनेशन का उपयोग कैसे करता है: http://apiwiki.twitter.com/Twitter-REST-API-Method:-friends%C2%A0ids - next_cursor और last_cursor को अगले/पिछले पृष्ठों के लिंक के रूप में माना जा सकता है। ये पृष्ठ तब भी काम करते हैं जब परिवर्तन के नीचे सूची।सूचकांक आधारित अंकन सूचियों के लिए काम नहीं करता है जो बहुत बदलते हैं। – mogsie