2012-02-12 9 views
33

क्या एक ही ग्राहक से एक ही सर्वर के लिए दो अलग वेबस्केट कनेक्शन होने का कोई लाभ है? मेरे लिए यह एक खराब डिजाइन पसंद प्रतीत होता है, लेकिन क्या कोई कारण है कि इसे बेहतर तरीके से क्यों काम करना चाहिए?एकाधिक वेबसाइकिल कनेक्शन

+0

क्या REQUEST_URI भी समान हैं? –

+0

@ सिप्लू हम्म। किसी को यूरी के माध्यम से जानकारी नहीं देना चाहिए क्योंकि यह केवल एक बार किया जाता है। इस मामले में, मान लें ** हाँ **। – Christian

+4

क्या करीबी मतदाता कृपया बता सकते हैं क्यों? ** मेरा प्रश्न वास्तव में रचनात्मक क्यों नहीं है? ** – Christian

उत्तर

56

कई कारण आप कि ऐसा करना चाह सकते हैं, लेकिन वे शायद (कम से कम अभी तक नहीं) भी आम नहीं हैं:

  • आप दोनों एन्क्रिप्टेड है और एन्क्रिप्ट नहीं किए गए डेटा को भेज रहे हैं/प्राप्त करना (उदाहरण के लिए कुछ डेटा भारी है लेकिन संवेदनशील नहीं है)।
  • आपके पास स्ट्रीमिंग डेटा और विलंबता संवेदनशील डेटा दोनों हैं: एक इंटरैक्टिव गेम की कल्पना करें जो कभी-कभी गेम के अंदर वीडियो स्ट्रीम करता है। आप नहीं चाहते हैं कि बड़ी मीडिया स्ट्रीम विलंबता संवेदनशील सामान्य गेम संदेशों की प्राप्ति में देरी हो।
  • आपके पास दोनों पाठ्यचर्या (उदा। जेएसओएन नियंत्रण संदेश) और बाइनरी डेटा (टाइप किए गए सरणी या ब्लब्स) हैं और अपनी खुद की प्रोटोकॉल परत को जोड़ने के लिए परेशान नहीं होना चाहते हैं क्योंकि WebSockets पहले से ही आपके लिए यह करता है।
  • आपके पास एकाधिक वेबसॉकेट उप-प्रोटोकॉल (यूआरआई के बाद वैकल्पिक सेटिंग) है जो आप समर्थन करते हैं और पृष्ठ एक से अधिक तक पहुंचना चाहता है (प्रत्येक वेबसाकेट कनेक्शन एक एकल उप-प्रोटोकॉल तक सीमित है)।
  • आपके पास एक ही वेब सर्वर और पोर्ट के पीछे बैठे कई अलग-अलग वेबसाकेट सेवाएं हैं। क्लाइंट प्रति कनेक्शन चुनने का तरीका यूआरआई पथ, यूआरआई योजना (डब्ल्यूएस या डब्ल्यूएसएस), सब-प्रोटोकॉल, या शायद क्लाइंट से सर्वर तक पहला संदेश भी निर्भर करता है।

मुझे यकीन है कि अन्य कारण भी हैं लेकिन मैं अपने सिर के ऊपर से सोच सकता हूं।

+0

+1 बहुत जानकारीपूर्ण! – Jonas

0

मैं वर्तमान में एक ही वेबसाइट पर दो कनेक्शन रखने के लिए एक समाधान की तलाश कर रहा हूं। मेरे कारण:

  • मैं QUnit में एक टेस्ट केस लिखा था और मैं कई ग्राहकों अनुकरण और सही प्रतिक्रियाओं
0

मैंने पाया कि यह ग्राहक तर्क बहुत सरल है जब आप कर सकते हैं के लिए विभिन्न ग्राहकों की जांच करना चाहते केवल सर्वर द्वारा प्रबंधित कुछ वस्तुओं के अपडेट की सदस्यता ले रहे हैं। एक चैनल के लिए कस्टम सदस्यता प्रोटोकॉल तैयार करने के बजाय, आप प्रत्येक तत्व के लिए बस एक सॉकेट खोल सकते हैं।

मान लीजिए कि आप

पर एक बाकी एपीआई के माध्यम से तत्वों का एक संग्रह प्राप्त करते हैं
http://myserver/api/some-elements 

आप इस प्रकार का सॉकेट यूआरएल का उपयोग कर एक भी तत्व के अपडेट के लिए सब्सक्राइब कर सकते हैं:

ws://myserver/api/some-elements/42/updates 
पाठ्यक्रम एक का

तर्क दे सकता है कि यह जटिल पृष्ठों के लिए स्केल नहीं करता है। हालांकि, छोटे और सरल अनुप्रयोगों के लिए यह आपके जीवन को बहुत आसान बना सकता है।

संबंधित मुद्दे