2011-12-15 18 views
16

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

मैं पुराने फैशन सर्वर मतदान से दूर रहना चाहता हूं। इसे यथासंभव वास्तविक समय के करीब होना चाहिए।

मुझे पहले कभी यह आवश्यकता नहीं थी और मैं समाधान की जांच कर रहा हूं। मेरा पहला विचार .NET client के साथ SignalR का उपयोग करना था। मैंने अभी तक सिग्नल के साथ काम नहीं किया है, लेकिन ऐसा लगता है कि यह एक समाधान हो सकता है। मुझे पता है कि यह उपलब्ध होने के आधार पर लंबी-मतदान, सर्वर-प्रेषित घटनाओं और वेबसाकेट पर एक अमूर्त है।

मैंने कॉलबैक और सेवा बसों के साथ डब्ल्यूसीएफ के बारे में संक्षेप में पढ़ा है, लेकिन अभी तक उनके बारे में कुछ भी नहीं पता है या क्या ये तकनीकें यहां लागू होती हैं। मैं उन लोगों से कुछ फीडबैक और सुझावों का उपयोग कर सकता हूं जिन्होंने पहले इसका सामना किया था। आपको इसे कैसे करना होगा?

+0

क्या क्लाइंट और सर्वर के बीच एक नियंत्रित नेटवर्क के भीतर कनेक्शन है, या यह "क्लाउड" पर है? –

+0

@ माइक - मान लें कि यह एक लैन है। –

उत्तर

0

यह सवाल दिलचस्प है।

हम वर्तमान में एक ऐसे अनुप्रयोग विकसित कर रहे हैं जो एकाधिक वेब सेवाओं के साथ इंटरैक्ट करता है। आवश्यकताओं में से एक यह है कि प्रत्येक ग्राहक को अन्य ग्राहकों द्वारा किए गए कार्यों के बारे में अवगत कराया जाना चाहिए।

इसे प्राप्त करने के लिए, हम एक वेब सेवा बनाने के बारे में सोच रहे हैं जिसका उद्देश्य केवल सूचित करने के लिए ग्राहकों की एक सूची बनाने के लिए है, और अधिसूचना की सामग्री, कब और अधिसूचित सामग्री के पीछे तर्क को संभालने के लिए है । लॉन्च होने पर ग्राहक उस सेवा के साथ पंजीकरण करेंगे। आपके द्वारा उल्लेखित कॉलबैक का उपयोग करके अधिसूचनाएं स्वयं की जाएंगी।

पूरी तरह से अलग वेब सेवा का उपयोग करने का कारण इस तथ्य के कारण था कि हमारे सभी मौजूदा लोगों को कनेक्शन की आवश्यकता होती है और प्रत्येक कॉल पर गिरा दिया जाता है। अधिसूचना वेब सेवा के साथ, जब तक ग्राहक चलते हैं, कनेक्शन को बनाए रखा जाना चाहिए।

मुझे खेद है कि मैं और अधिक सहायता नहीं कर सकता, क्योंकि हम खुद को ऐसी प्रणाली विकसित करने की प्रक्रिया में हैं। मैं इस विषय पर प्रतिक्रिया प्राप्त करने में भी रूचि रखता हूं।

7

यह डब्ल्यूसीएफ और duplex contracts के साथ काफी आसानी से किया जा सकता है। आप ऑपरेशन को परिभाषित कर सकते हैं कि क्लाइंट सर्वर (किसी भी वेब सेवा की तरह) पर प्रदर्शन कर सकता है और इसके अतिरिक्त आप क्लाइंट पर सर्वर (यानी एक रिवर्स वेब-सेवा) पर प्रदर्शन कर सकते हैं। संहिता के अनुसार, वे दोनों सरल विधि कॉल हैं। क्लाइंट में ऐसे विधियां हैं जो सर्वर पर ऑपरेशन कॉल करती हैं और इसे एक ऑब्जेक्ट भी प्रदान करना चाहिए जो कॉलबैक अनुबंध लागू करता है, जो एक इंटरफ़ेस है जिसे सर्वर कॉल कर सकता है और क्लाइंट को कार्यान्वयन प्रदान करना होगा। डेटा और संदेशों के सभी क्रमिकरण/deserialization और सभी निम्न स्तर के नेटवर्क संचालन डब्ल्यूसीएफ द्वारा संभाला जाता है, तो आपको इसके बारे में चिंता करने की ज़रूरत नहीं होगी।

WCF दो बाइंडिंग (या 'प्रोटोकॉल') का उपयोग कर द्वैध ठेके का समर्थन करता है:

  1. WSDualHttpBinding - यह दो SOAP आधारित HTTP श्रोताओं, सर्वर पर एक और ग्राहक पर एक जरूरत पर जोर देता। जब ग्राहक सर्वर से संपर्क करना चाहता है, तो यह सर्वर पर HTTP अनुरोध करता है। जब सर्वर क्लाइंट से संपर्क करना चाहता है, तो यह क्लाइंट को HTTP अनुरोध करता है। इस दृष्टिकोण का लाभ यह है कि कोई भी नेटवर्क कनेक्शन बेड़े हो रहा है, और इसे खुला रखा नहीं जाता है (अधिकांश HTTP कनेक्शन के साथ), और इसलिए यह बड़ी संख्या या समवर्ती ग्राहकों का समर्थन कर सकता है।मुख्य नुकसान यह है कि यह शायद इंटरनेट पर अधिकांश क्लाइंट कंप्यूटरों के साथ काम नहीं करेगा क्योंकि वे आम तौर पर एनएटी के पीछे होते हैं (इंटरनेट पर सर्वर से सर्वर संचार के लिए एक गैर-मुद्दा या इंट्रानेट या लैन के अंदर संचार के किसी भी प्रकार) । अधिक जानकारी के लिए, मेरे other answer देखें।

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

डब्ल्यूसीएफ का लाभ यह है कि आप अपने कोड को बदले बिना दो बाइंडिंग के बीच स्विच कर सकते हैं। यह आवश्यक है कि कॉन्फ़िगरेशन (.config फ़ाइल) बदल रहा है।

आप जिस भी तरह से चुनते हैं, आप दोनों दिशाओं (नेटवर्क विलंबता अनुमति, निश्चित रूप से) में निकट-तत्काल संचार करने में सक्षम होंगे। मुझे सिग्नलआर की आवश्यकता नहीं दिखाई देती है जब आपके पास इतनी समृद्ध, शक्तिशाली और उपयोगकर्ता के ढांचे के लिए आसान है जैसे कि डब्ल्यूसीएफ आपके निपटान में। यदि आप ब्राउज़र में चलकर बाध्य थे, तो सिग्नलआर समझ में आएगा। चूंकि आप .NET में चल रहे हैं, यह केवल अनावश्यक घर्षण पेश करेगा।

+1

मैं डब्ल्यूसीएफ के इस क्षेत्र में और अधिक देखूंगा, लेकिन सिग्नलआर पर विचार करने का कारण यह है क्योंकि मेरा अनुभव यह है कि डब्ल्यूसीएफ अनावश्यक घर्षण पेश करता है। –

3

आपको फ्रोजन माउंटेन से WebSync पर देखना चाहिए। मैंने इसे अतीत में महान परिणामों के साथ उपयोग किया है। यह सब आपको चाहिए। वे एक होस्टेड सेवा 'वेबसंक ऑन डिमांड' भी प्रदान करते हैं। वे एक मुफ्त उत्पाद भी प्रदान करते हैं (लेकिन 10 समवर्ती उपयोगकर्ताओं तक)। यह एक कॉमर्शियल उत्पाद है। यदि आप सभी नलसाजी नहीं करना चाहते हैं, तो WebSync आपको एपीआई का उपयोग करने के लिए तैयार करता है, आप बस उपयोग करना शुरू कर सकते हैं और तेजी से जा सकते हैं। मैंने सिग्नलआर के बारे में सुना/पढ़ा है, अभी तक इसका उपयोग नहीं किया है, लेकिन सिग्नलआर अल्फा/बीटा में प्रतीत होता है, जबकि वेबसिंक बहुत परिपक्व है।

0

आप एक डब्ल्यूसीएफ सेवा बना सकते हैं जहां wpf क्लाइंट स्टार्टअप पर themselve पंजीकृत करते हैं। फिर प्रत्येक wpf एक msmq या rabbitmq सर्वर के साथ संवाद कर सकता है जहां वे क्लाइंट नाम/अद्वितीय आईडी के आधार पर बनाई गई अपनी स्वयं की कतार मतदान करेंगे। सर्वर की तरफ, आपके पास एक ऐसी सेवा हो सकती है जो डेटा को कतार में धक्का देगी क्योंकि डेटा प्रत्येक क्लाइंट के लिए निर्धारित स्थितियों के आधार पर उपलब्ध है।

+0

मैं मतदान नहीं करना चाहता हूं। –

+0

आप हमेशा प्रत्येक मशीन पर कतार रख सकते हैं जो WPF ऐप चलाता है और कतार से पढ़ता है। जब तक आप WPF का उपयोग कर रहे हैं, आपको डेटा प्राप्त करने के लिए कुछ मतदान करने की आवश्यकता होगी, सिवाय इसके कि आप डब्ल्यूसीएफ कॉलबैक का उपयोग करते हैं जो कि कतार का उपयोग करने के रूप में विश्वसनीय नहीं है, जहां आपने अपना डेटा – rpgmaker

+0

जारी रखा है, यह विस्तृत क्यों नहीं है। –

4

सिग्नलआर जैसी प्रौद्योगिकियों का बिंदु सर्वर और वेब क्लाइंट के बीच रीयलटाइम संचार की मांग को पूरा करना है। वे पुराने वेब ब्राउज़र के लिए वेबस्केट्स और पुराने/हैकर संचार तंत्र में फॉलबैक का लाभ उठाते हैं।

यदि आपका पर्यावरण एक लैन और आपके क्लाइंट को .NET ऐप होने जा रहा है तो आप एक टीसीपीएस सर्वर और एकाधिक टीसीपीसीएलेंट्स का उपयोग कर सकते हैं। जब आपके वेब सर्वर को आपके टीसीपीएस सर्वर (शायद एक संदेश बस पर एक संदेश डालकर) को भेजने के लिए एक अपडेट/संदेश होता है जो कनेक्ट क्लाइंट को सूचित कर सकता है। रीयलटाइम वेब प्रौद्योगिकियों ऐसा करने का एक शानदार तरीका है लेकिन यह वास्तव में निर्भर करता है कि आपके वर्तमान आवश्यकताओं कर रहे हैं और क्या भविष्य के लिए अपनी योजनाओं हैं:

  • आप SignalR की कोशिश करना चाहते हैं - यदि हाँ, तो यह काम करेंगे और आपको शायद बहुत मज़ा आएगा। यह भविष्य की परियोजनाओं के लिए भी उपयोगी हो सकता है और आपके धनुष में अच्छी स्ट्रिंग बन सकता है। यदि नहीं, तो एक टीसीपी क्लाइंट और टीसीपीएस सर्वर दृष्टिकोण सुपर-सरल और तेज़ हो सकता है।
  • क्या आपके पास भविष्य में अधिसूचनाएं प्राप्त करने में सक्षम होने के लिए अन्य प्रकार के वेब क्लाइंट की आवश्यकता है? - हाँ, सिग्नलआर या अन्य परिपक्व self hosted realtime web technology एक बेहतर समाधान हो सकता है।नहीं - टीसीपीएस सर्वर/क्लाइंट
  • क्या आप अपने LAN के बाहर डेटा वितरित करने की योजना बना रहे हैं? हां - एक स्वयं होस्टेड विकल्प या घटना hosted solution .NET पुस्तकालयों के साथ रखरखाव ओवरहेड (अस्वीकरण: मैं Pusher के लिए काम करता हूं जो इस तरह की सेवा प्रदान करते हैं)। नहीं - स्वयं होस्टेड या टीसीपीएस सर्वर/ग्राहक।
  • गति की बात कितनी है? यदि यह वास्तव में मायने रखता है तो बिल्कुल कोई ओवरहेड वाला एक टीसीपी कनेक्शन सबसे तेज़ विकल्प नहीं होगा। दूसरा सबसे अच्छा विकल्प वेबसाकेट होगा, फिर HTTP स्ट्रीमिंग HTTP लांग-पोलिंग के बाद होगा।

नोट: हालांकि मैं TCPServer कह रहा हूँ/ग्राहक सरल दृष्टिकोण मैं जोर देना है कि यह भी हो नहीं हो सकता है करना चाहते हैं हो सकता है। वेबसाकेट्स वास्तव में एक रोमांचक तकनीक है और टीसीपी क्लाइंट तकनीक की तुलना में कई तरीकों से अधिक सुलभ है, इसलिए किसी भी सर्वर और क्लाइंट के बीच द्वि-दिशा संचार के लिए प्रमुख तकनीक बन सकती है *

मैं डुप्लेक्स अनुबंधों पर टिप्पणी नहीं कर सकता लेकिन मेरी समझ थी कि वे स्थापित कनेक्शन जारी नहीं थे इसलिए वे वास्तव में एक मतदान समाधान हैं - मैं गलत हो सकता था।

+0

डुप्लेक्स अनुबंध कम से कम ढांचे के साथ आपूर्ति की जाने वाली किसी भी बाइंडिंग के साथ मतदान का उपयोग नहीं करते हैं (यानी आप अपनी खुद की कस्टम बाइंडिंग लिख सकते हैं जो पागल चीजों के सभी प्रकार करता है)। –

+0

वे क्या उपयोग करते हैं? HTTP स्ट्रीमिंग? – leggetter

+0

नहीं - मेरा उत्तर देखें। –

3

मैं एक पब/उप सेवा का उपयोग कर डब्ल्यूपीएफ ग्राहकों को घटनाओं को संवाद करने के लिए एक हल्के वजन का अभी भी आसान तरीका मूल्यांकन कर रहा था। मुझे गारंटीकृत संदेश वितरण की आवश्यकता नहीं थी इसलिए मैसट्रांसिट या एनएस सर्विसबस जैसे समाधान बहुत भारी लगते थे क्योंकि उन्हें कतारों की आवश्यकता होती है (एमएसएमक्यू या अन्यथा)। मुझे यह भी आवश्यकता थी कि समाधान .NET 4.0 क्लाइंट प्रोफाइल के रूप में उपलब्ध हो।

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

प्रति ब्रेज के Blog पर एक और समाधान आया जो प्रतिक्रियाशील एक्सटेंशन के साथ सिग्नल का उपयोग करता है। मैंने उनके कार्यान्वयन की कोशिश नहीं की है और मुझे यकीन नहीं है कि क्या इसे पूर्ण प्रोफाइल की आवश्यकता है लेकिन यह एक अच्छा पढ़ा है!

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