डेडलाइन उस क्रिया को दें जो नेटवर्क काम रद्द कर सकती है। प्रॉक्सी के ज़रिए कॉन्फ़िगर किए गए मौजूदा .NET HttpClient के लिए:

using var deadline = new CancellationTokenSource(TimeSpan.FromSeconds(20));
using var response = await client.GetAsync(uri, deadline.Token);

एप्लिकेशन client और uri देता है। यह ओवरलोड रद्दीकरण टोकन लेता है; इसके टास्क का इंतज़ार करने के आसपास का टाइमआउट सिर्फ़ उसी कॉलर का इंतज़ार सीमित करेगा। पूर्णता फ़्लैग को पोल करने में भी वही समस्या है: कॉलर चला जा सकता है जबकि सॉकेट और वर्कर व्यस्त रहते हैं।

रद्दीकरण क्लाइंट के कार्यान्वयन और सफ़ाई पथ का पालन करता है। यह वादा नहीं करता कि हर निचले स्तर की क्रिया किसी सटीक निर्देश पर रुकेगी। उस पथ को पूरा होने दें और उन संसाधनों को मुक्त करें जिनका स्वामित्व क्रिया के पास है। डिज़ाइन में अलग से नियंत्रित बॉडी पढ़ने को शामिल करें; आधुनिक .NET ResponseHeadersRead क्रिया के लिए, वही टोकन बॉडी पढ़ने के ज़रिए भेजें। अन्य क्लाइंट अपने स्वयं के रद्दीकरण, निरस्त और सफ़ाई इंटरफ़ेस देते हैं।

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

दूरस्थ परिणाम के लिए अलग हैंडलिंग चाहिए। रद्दीकरण होने तक गंतव्य को सबमिशन मिल चुका हो सकता है। एप्लिकेशन की रिकवरी या idempotency नीति अपनाएँ; स्थानीय काम रोकने से दूरस्थ क्रिया पूर्ववत नहीं होती।

संबंधित लेख