net.tcp, http, आदि के लिए सामान्य संख्या में। (कुछ विचारों के लिए ऊपर टिप्पणियां देखें; यह अन्य प्रोटोकॉल/बाइंडिंग/आदि के लिए भी अलग हो सकता है।)
कारण यह है कि सर्वर पक्ष पर डब्ल्यूसीएफ आधारभूत संरचना कोड का उपयोग करने से पहले चैनल का उपयोग नहीं करेगा सेवा संचालन के कार्यान्वयन कोड और प्रतिक्रिया marshalling। केवल तभी यह प्रतिक्रिया भेजने का प्रयास करेगा और इस बिंदु पर यह पहचान लें कि कनेक्शन पहले से ही ग्राहक द्वारा निरस्त कर दिया गया है।
जब सर्वर उस त्रुटि को प्राप्त करता है तो उपयोगकर्ता कोड (आपका सेवा संचालन कार्यान्वयन) पहले से ही किया जा चुका है और इस प्रकार आप वहां से उस पर प्रतिक्रिया नहीं दे सकते। यह एक प्रेषक, या अन्य विस्तार बिंदु के भीतर से संभव हो सकता है, लेकिन व्यक्तिगत रूप से मैंने कोशिश नहीं की है। हालांकि, यह आपके सर्वर को अनावश्यक काम से भी नहीं बचाएगा, क्योंकि जैसा कि कहा गया है, क्लाइंट डिस्कनेक्ट तब भी पहचाना जाएगा जब सर्वर वास्तव में उत्तर भेजने का प्रयास करता है।
ऐसे मुद्दों को कम करने का एक "सरल" तरीका कई सेवा संचालन/कॉल (अगर संभव हो तो काम को विभाजित करना है, और प्रक्रिया में सर्वर-साइड स्थिति को गलती से शुरू नहीं करना)। या जैसा कि अन्य ने कहा है, क्लाइंट ने "पिंग" इंटरफेस को कार्यान्वित किया है जो सर्वर यह जांचने के लिए उपयोग कर सकता है कि क्लाइंट अभी भी "जीवित" है और प्रतिक्रिया अभी भी जरूरी है।
स्रोत
2015-09-21 11:55:21
Async टाइमआउट कार्य के तरीके को नहीं बदलेगा। – usr
डब्ल्यूसीएफ एसिंक ऑपरेशंस के पास कोई रिटर्न वैल्यू नहीं है और जब तक ऑपरेशन सर्वर की तरफ पूरा नहीं हो जाता तब तक प्रतीक्षा न करें। मेरा टाइमआउट (कभी-कभी) लंबे सर्वर-साइड प्रोसेसिंग के कारण होता है, कोई नेटवर्क समस्या नहीं होती है। इस प्रकार एसिंक ऑपरेशन इस मुद्दे को हल करेगा, लेकिन मैं एक अलग समाधान की तलाश में हूं। –
जब आप डब्ल्यूसीएफ एसिंक कहते हैं, तो क्या आप 'async/await', या OneWay ऑपरेशन अनुबंधों के बारे में बात कर रहे हैं? आपकी टिप्पणी से, यह OneWay संचालन की तरह लगता है। जहां तक क्लाइंट पर टाइमआउट का पता लगाना है, मुझे यकीन नहीं है कि आप क्लाइंट साइड पर कर सकते हैं। सर्वर को यह देखने के लिए क्लाइंट को मतदान करने का कोई तरीका होगा कि यह अभी भी ऊपर था - शायद एक डुप्लेक्स बाध्यकारी। – Tim