2008-10-15 5 views
13

मैं डब्ल्यूसीएफ का उपयोग कर नेट 3.5 में क्लाइंट/सर्वर एप्लिकेशन विकसित कर रहा हूं। असल में, एक लंबी चल रही ग्राहक सेवा (कई मशीनों पर) नेटटीसीपी बाइंडिंग पर सर्वर से डुप्लेक्स कनेक्शन स्थापित करती है। सर्वर तब क्लाइंट के कॉलबैक अनुबंध का उपयोग कुछ ऑन-डिमांड ओपेरेशंस करने के लिए करता है, जिस पर क्लाइंट एसिंक्रोनस फैशन (काफी मानक सामान मुझे लगता है) में प्रतिक्रिया देता है। मैं अधिकांश संचार को संभालने के लिए डुप्लेक्स क्लाइंटबेस क्लास को उप-वर्गीकृत करता हूं।यदि यह गलती हो जाती है तो मैं स्वचालित रूप से एक डुप्लेक्स चैनल को फिर से स्थापित कैसे करूं?

दुर्भाग्य से, जब कुछ दोनों छोर पर गलत हो जाता है (इस तरह के एक नेटवर्क विफलता, अनपेक्षित अपवाद, आदि), चैनल गर्भपात गलती हो जाता है/और बाद के सभी कार्रवाई विफल। मैं इस सीमा को गैर-डुप्लेक्स चैनलों में एक रिकवरिंग क्लाइंटबेस क्लास बनाकर प्राप्त कर चुका हूं जो क्लाइंट ने गलती की है और ऑपरेशन को फिर से चालू करते समय स्वचालित रूप से उठाया है।

तो मेरे सवाल है, वहाँ जब एक डुप्लेक्स चैनल गलती है का निर्धारण करने का एक स्थापित तरीका है? सर्वर या क्लाइंट पर मुझे यह कहां से जांचना चाहिए? यह विफल होने के कारण, मुझे यह सुनिश्चित करने के लिए क्या विकल्प हैं कि कनेक्शन फिर से स्थापित हो जाए?

अद्यतन: मैं कुछ सलाह द्वैध चैनल, जहां सर्वर एक कॉलबैक चैनल कि गलती किया गया था उपयोग करने के लिए कोशिश कर सकते हैं के लिए विशिष्ट की तलाश में हूँ। इस प्रकार, मुझे कुछ ऐसा चाहिए जो चैनल से कुछ घटित होने पर तुरंत पुनः कनेक्ट/पुनः सदस्यता ले लेगा। फिलहाल मैं चैनल के समापन कार्यक्रम को सुन रहा हूं और अगर राज्य कुछ भी बंद है तो इसे पुनर्निर्माण कर रहा हूं। यह एक तरह से काम करता है, लेकिन यह hacky लगता है ...

उत्तर

1

निकोलस एलन, WCF टीम की ओर से इस बात के लिए सुझाव है:

http://blogs.msdn.com/drnick/archive/2007/11/05/custom-transport-retry-logic.aspx

उनका यह सुझाव चैनल स्तर पर इस संभाल करने के लिए है। चैनल स्तर थोड़ा अच्छा है, क्योंकि आप इसे कस्टम क्लाइंट बेस क्लास की आवश्यकता के बजाय व्यवहार के माध्यम से किसी बाध्यकारी स्टैक में प्लग कर सकते हैं।

+3

क्या आप शायद इसका एक उदाहरण प्रदान कर सकते हैं? लेख सिर्फ विचार को सुझाता है, लेकिन कार्यान्वयन के लिए कोई संकेत नहीं देता है। – Jacob

+0

+1 जैकब। क्या किसी को यह काम करने के बारे में कोई जानकारी मिली है? मुझे वर्तमान में अपने पुन: कनेक्शन व्यवहार को लागू करने के लिए महल गतिशील प्रॉक्सी का उपयोग करना पड़ा है, लेकिन मैं इस व्यवहार को डब्ल्यूसीएफ के माध्यम से जोड़ना चाहता हूं। मैं विभिन्न डब्ल्यूसीएफ ब्लॉग पढ़ रहा हूं लेकिन यह अभेद्य है और मेरे पास कोई संकेत नहीं है कि कहां से शुरू किया जाए - यहां तक ​​कि सरल एक्सटेंशन को वर्गों और कॉन्फ़िगरेशन के रीम्स के लोड की आवश्यकता होती है - यह परेशान है। –

+0

अपनी सेवा पर स्पष्ट ICommunicationObject इंटरफ़ेस के माध्यम से फ़ॉल्ट किए गए ईवेंट में इवेंट हैंडलर जोड़ें। घटना हैंडलर में, Abort() चैनल और एक नया चैनल बनाएँ। – Jakub

0

मैं कुछ इसी तरह की समस्याओं पड़ा है, और मुझे ऐसा लगता है कि इन लंबे समय से चल कॉल और अधिक या कम असमर्थित हैं।

WCF कम चल रहा है कॉल के लिए इस्तेमाल किया जा करने के लिए बनाया जा रहा है। सेवाएं, जिन्हें बुलाया जाता है, कुछ छोटी चीजें करते हैं, और समाप्त हो जाते हैं।

मैंने अपने अनुप्रयोगों को काम के छोटे सामानों में दोहराया। तो एक बड़ी लंबी दौड़ वाली वस्तु के बजाय अब मुझे बहुत सी छोटी चीजें मिलीं। बेशक, कभी-कभी हासिल करना संभव नहीं होता है। तब मुझे स्थिर नेटवर्क कनेक्शन के लिए प्रार्थना करनी पड़ी (अपवादों को पकड़ा जा सकता है, इसलिए गलती वास्तव में एक समस्या नहीं है)।

3

मैं लंबे समय से चल रहा है सत्र (मिनट घंटे) में की समस्या की अनुभव किया है। मुझे यकीन नहीं है कि यह डब्ल्यूसीएफ है, मुझे यकीन है कि इसका नेटवर्क स्तर निश्चित है।

मैं पूरी तरह से डुप्लेक्स से दूर करने की सोच रहा हूं। यह एक वास्तविक उपद्रव है जो कनेक्शन की स्थिति का प्रबंधन करने की कोशिश कर रहा है।

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

आपके प्रश्न का उत्तर नहीं देता है, लेकिन मुझे आपका दर्द महसूस होता है।

0

मुझे लगता है कि आपको वास्तव में दोषपूर्ण घटना पर सुनना चाहिए। आप इसे दोनों अंत में सुन सकते हैं, क्लाइंट के अंत में मुझे लगता है कि आप पहले से ही हैंडलिंग कर रहे हैं, सर्वर का अंत ऑपरेशनकॉन्टेक्स्ट है। Current.Channel.events।

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

ग्राहक अंततः गलती हो जाएंगे और सर्वर के साथ हैंडशेक फिर से करना चाहिए, जो बिंदु सर्वर को असंतुलित कॉल भेजना चाहिए।

असल में एक ग़लत/बंद चैनल से पुनर्प्राप्त करने का एकमात्र तरीका इसे एक नए स्थान से बदल रहा है, हालांकि, सबसे महत्वपूर्ण बात यह है कि आपको वास्तव में डिस्कनेक्ट का पता लगाना चाहिए, मुझे लगता है कि विश्वसनीय सत्र सक्षम होने पर दोषपूर्ण घटना को बढ़ाएगा ज्यादातर मामले का समय। वैकल्पिक रूप से, आप दोनों छोरों पर दिल की धड़कन संदेश भेज सकते हैं ताकि चैनल को "परीक्षण" किया जा सके।

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