के लिए सर्वश्रेष्ठ समाधान हम सर्वर से सर्वर पर डेटा धक्का देना चाहते हैं लेकिन केवल HTTP (पोर्ट 80) का उपयोग कर सकते हैं। संदेश के लिए सबसे अच्छा समाधान क्या है? एक विचार Comet है। क्या अन्य विचार या ढांचे हैं जो प्रस्ताव देते हैं कि HTTP पर जेएमएस कहें। (हां, ActiveMQ इसे भी समर्थन देता है, लेकिन WAGGLY IMHO। और JXTA भी इसका समर्थन करता है लेकिन कॉन्फ़िगरेशन जटिल है। कुछ सरल पसंद किया जाता है।)जावा HTTP पुश (मैसेजिंग)
कई कारणों से सबसे आसान समाधान धूमकेतु आधारित दृष्टिकोण (जैसे आपने जिक्र किया)। इसका मतलब है क्लाइंट (जिनके लिए आप संदेशों को "धक्का" देना चाहते हैं) लंबे समय तक चलने वाले HTTP कनेक्शन खोलें। वे कनेक्शन तब तक खुला रहता है जब तक वे समय समाप्त नहीं करते या आप ग्राहक को एक संदेश भेजते हैं। जैसे ही ग्राहक होता है, ग्राहक एक नया कनेक्शन खोलता है।
सीधे ग्राहकों से कनेक्ट करना कई कारणों से समस्याग्रस्त हो सकता है: वे फ़ायरवॉल के पीछे हो सकते हैं जो इसे अस्वीकार करते हैं, वे प्रॉक्सी के पीछे हो सकते हैं और इसी तरह।
जब तक कि आपके ग्राहक वास्तविक सर्वर नहीं हैं (इस मामले में आप वास्तव में ग्राहक हैं), उन्हें संपर्क करें और नकली धक्का के लिए प्रतिक्रिया भेजें।
हमने WAS Web 2.0 Feature Pack का उपयोग कर जेएमएस के संयोजन के साथ सीओएमईटी का उपयोग किया; असल में सर्वर ने जेएमएस सब्सक्राइब किया और सीओएमईटी ने ब्राउज़र को संदेश धक्का दिया। एक डेवलपर के रूप में यह "महसूस किया" जैसे ब्राउज़र जेएमएस की सदस्यता ले रहा था। यह "अभी काम किया" इसलिए हमने विकल्पों के लिए और अधिक नहीं देखा।
मैं एक परिवहन के रूप में HTTP का उपयोग कर ब्राउज़र में एक शुद्ध जावास्क्रिप्ट जेएमएस कार्यान्वयन की कल्पना कर सकता हूं लेकिन मेरा अनुमान यह है कि यह बहुत भारी वजन होगा। मुझे ऐसा कोई कार्यान्वयन नहीं है।
पहले से चर्चा किए गए लोगों के लिए वैकल्पिक दृष्टिकोण (यानी धूमकेतु आदि) ग्राहक में मतदान लागू करना है। उस दृष्टिकोण का नकारात्मक पक्ष यह है कि आपको अनिवार्य रूप से संदेश/घटना के समय से देरी हो जाती है और जब तक क्लाइंट इसे प्राप्त नहीं करता है। यदि आपका आवेदन ऐसी देरी से बहुत संवेदनशील है, तो मतदान समाप्त हो गया है।
यदि कुछ निश्चित विलंब (कम से कम कुछ सेकंड के क्रम में) स्वीकार्य है, तो मतदान HTTP प्रोटोकॉल के दुरुपयोग से कम है। यह डिफ़ॉल्ट कतार संदेशों द्वारा सर्वर के रूप में अस्थायी नेटवर्क परेशानियों के खिलाफ भी अधिक मजबूत है और क्लाइंट अपने शेड्यूल पर उपलब्ध नहीं होने पर परेशान नहीं होगा।
मतदान और दीर्घकालिक कनेक्शन के बीच वास्तव में कोई बड़ा अंतर नहीं है। दोनों मामलों में आप एक मतदान में प्रवेश करते हैं, और यह तत्काल वापस आ जाएगा, या कुछ देरी के साथ। जितना अधिक विलंब होता है उतना ही कम कनेक्शन आपको खोलना है। सभी मामलों में समाप्त या अनुत्तरित कॉल जैसी समस्याएं अगले चुनाव की ओर ले जाती हैं। HTTP/1.1 के अंदर (टीसीपी) कनेक्शन आम तौर पर खुला रहता है। – eckes
Atmosphere और DWR खुले स्रोत ढांचे दोनों हैं जो जावा में धूमकेतु को आसान बना सकते हैं।
मैंने धूमकेतु, राफेल, बायएक्स, जावा और मेवेन का उपयोग करके एक उदाहरण ऐप बनाया है जो पैस क्लाउडबीस चला रहा है और इसके बारे में एक ब्लॉग पोस्ट लिखा है, उम्मीद है कि यह किसी के लिए सहायक होगा।
http://geeks.aretotally.in/thinking-in-reverse-not-taking-orders-from-yo
लिंक काम नहीं कर रहा है। –
क्या यह सही है? जब ब्राउज़र ब्राउज़र पर आता है तो एक नया कनेक्शन खोला जाता है? – djna
ग्राहक को नया कनेक्शन खोलने के लिए प्रोग्राम किया जाना चाहिए। अगर ऐसा नहीं है कि सर्वर के पास क्लाइंट के साथ संवाद करने का कोई तरीका नहीं है। – cletus
मुझे खेद है। समझ में परेशानी हो रही है। ग्राहक ने एक दीर्घकालिक HTTP कनेक्शन खोला है। सर्वर वहां संदेश भेजता है - है ना? फिर आप कहते हैं, "वे कनेक्शन तब तक खुलते रहते हैं जब तक वे समय निकालते हैं या आप ग्राहक को एक संदेश भेजते हैं। जैसे ही ग्राहक होता है, ग्राहक एक नया कनेक्शन खोलता है।" लगता है जैसे हम एक दूसरा कनेक्शन खोल रहे हैं। क्यूं कर? जिस संदेश को हमने अभी प्राप्त किया है वह उस डेटा में शामिल है जिसे हम चाहते हैं, है ना? – djna