Long Polling vs WebSocket C#: रियल-टाइम के लिए कौन सा बेहतर?

लंबा कॉल या स्थायी चैनल: C# रियल-टाइम डेटा कैसे भेजता है

कल्पना करें: आप C# में एक चैट ऐप लिख रहे हैं। या शेयर बाजार का टर्मिनल। या नोटिफिकेशन सिस्टम। क्लाइंट डेटा का इंतजार कर रहा है — और लंबा इंतजार करने को तैयार नहीं। पहले डेवलपर्स जुगाड़ करते थे: टाइमर लगाते, हर 5 सेकंड में सर्वर को हिट करते, अनावश्यक रिक्वेस्ट बढ़ाते। आज हमारे पास दो सभ्य तरीके हैं — Long Polling और WebSocket। दोनों सर्वर को बिना क्लाइंट के स्पष्ट अनुरोध के डेटा भेजने देते हैं। लेकिन ये बिल्कुल अलग तरह से काम करते हैं।

इस लेख में हम C# (ASP.NET Core) में दोनों तरीकों को लागू करना, गति, लोड और जटिलता के आधार पर तुलना करना, और समझेंगे कि आपके प्रोजेक्ट के लिए क्या चुनना चाहिए। चलिए शुरू करते हैं।

Long Polling क्या है? (और यह कोई जादू क्यों नहीं है)

Long Polling सामान्य HTTP के ऊपर रियल-टाइम का अनुकरण है। क्लाइंट सर्वर को एक रिक्वेस्ट भेजता है, लेकिन सर्वर तुरंत जवाब नहीं देता। वह कनेक्शन को तब तक खुला रखता है जब तक कोई नई घटना न हो (या टाइमआउट न हो जाए)। जैसे ही डेटा तैयार होता है — सर्वर जवाब भेजता है, क्लाइंट उसे प्रोसेस करता है और तुरंत एक नया "लंबा" अनुरोध शुरू करता है।

यह एक चालाक ट्रिक है जो किसी भी HTTP सर्वर और किसी भी ब्राउज़र पर काम करती है। लेकिन इसकी एक कीमत है: हर कनेक्शन सर्वर की मेमोरी में लटका रहता है, और अगर हजारों क्लाइंट हों — तो यह एक समस्या बन जाती है।

C# (ASP.NET Core) में Long Polling का उदाहरण

चलिए एक सरल कंट्रोलर लिखते हैं जो नोटिफिकेशन कतार का अनुकरण करता है। क्लाइंट एक एंडपॉइंट को हिट करता है, सर्वर नए डेटा (जैसे Channel<string> से) का इंतजार करता है और उसे भेजता है।

using Microsoft.AspNetCore.Mvc;\nusing System.Threading.Channels;\n\n[ApiController]\n[Route("api/[controller]")]\npublic class NotificationsController : ControllerBase\n{\n    private static readonly Channel<string> _channel = Channel.CreateUnbounded<string>();\n\n    // नोटिफिकेशन प्रकाशित करने का एंडपॉइंट (जैसे किसी अन्य सेवा से)\n    [HttpPost("publish")]\n    public async Task<IActionResult> Publish([FromBody] string message)\n    {\n        await _channel.Writer.WriteAsync(message);\n        return Ok("नोटिफिकेशन भेज दिया गया");\n    }\n\n    // Long Polling: क्लाइंट तब तक इंतजार करता है जब तक नया संदेश न आए\n    [HttpGet("long-poll")]\n    public async Task<IActionResult> LongPoll(CancellationToken cancellationToken)\n    {\n        // नए संदेश का इंतजार करें; अगर कुछ नहीं है — 30 सेकंड तक प्रतीक्षा करें\n        using var cts = CancellationTokenSource.CreateLinkedTokenSource(cancellationToken);\n        cts.CancelAfter(TimeSpan.FromSeconds(30));\n\n        try\n        {\n            var message = await _channel.Reader.ReadAsync(cts.Token);\n            return Ok(new { data = message });\n        }\n        catch (OperationCanceledException)\n        {\n            // टाइमआउट — खाली जवाब लौटाएं, क्लाइंट अनुरोध दोहराएगा\n            return Ok(new { data = (string?)null });\n        }\n    }\n}\n

क्लाइंट (JavaScript) कुछ इस तरह दिखेगा:

async function startLongPoll() {\n    while (true) {\n        const response = await fetch('/api/notifications/long-poll');\n        const result = await response.json();\n        if (result.data) {\n            console.log('नया नोटिफिकेशन:', result.data);\n        }\n        // तुरंत नया poll शुरू करें\n    }\n}\nstartLongPoll();\n

सब कुछ सरल है। लेकिन एक खामी है: अगर सर्वर रीस्टार्ट हो जाए या क्लाइंट का कनेक्शन टूट जाए — डेटा खो जाएगा। Long Polling डिलीवरी की गारंटी नहीं देता।

WebSocket: C# में दो-तरफा सुरंग

WebSocket TCP के ऊपर दो-तरफा संचार का एक पूर्ण प्रोटोकॉल है। हैंडशेक (सामान्य HTTP GET जिसमें अपग्रेड होता है) के बाद, क्लाइंट और सर्वर सीधे बात करते हैं, बिना HTTP हेडर के अतिरिक्त खर्च के। सर्वर किसी भी समय संदेश भेज सकता है, और क्लाइंट इसे तुरंत प्राप्त करेगा।

ASP.NET Core में WebSocket बिल्ट-इन आता है। किसी तीसरे पक्ष की लाइब्रेरी की जरूरत नहीं है (हालांकि SignalR इसे और भी आसान बनाता है, लेकिन हम यहां रॉ WebSocket पर ध्यान देंगे)।