Swift में Long Polling बनाम WebSocket: 2025 में iOS के लिए क्या चुनें

परिचय: iOS डेवलपर की शाश्वत दुविधा

कल्पना करें: आप एक मैसेंजर या स्टॉक ट्रेडिंग ऐप लिख रहे हैं। उपयोगकर्ता रीयल-टाइम सूचनाओं की प्रतीक्षा कर रहा है, और आपके सामने विकल्प है — Long Polling या WebSocket? Swift में, दोनों दृष्टिकोणों का अपना स्थान है, लेकिन प्रत्येक की अपनी बारीकियाँ हैं। इस लेख में, हम केवल फायदे और नुकसान सूचीबद्ध नहीं करेंगे, बल्कि वास्तविक कोड उदाहरण, प्रदर्शन, बैटरी पर प्रभाव का विश्लेषण करेंगे और चयन के लिए एक स्पष्ट एल्गोरिदम देंगे। चलिए शुरू करते हैं!

Swift में Long Polling क्या है? (और यह 'अनंत अनुरोध' क्यों नहीं है)

Long Polling एक क्लासिक HTTP अनुरोध है जिसे सर्वर तुरंत बंद नहीं करता, बल्कि तब तक खुला रखता है जब तक कोई नई घटना न हो या टाइमआउट समाप्त न हो जाए। Swift में, इसे कस्टम timeoutIntervalForRequest के साथ URLSession के माध्यम से कार्यान्वित किया जाता है।

कई लोग Long Polling को सामान्य polling (जहाँ क्लाइंट हर 5 सेकंड में सर्वर से अनुरोध करता है) के साथ भ्रमित करते हैं। अंतर यह है कि Long Polling में, सर्वर स्वयं डेटा को 'पुश' करता है जैसे ही वह उपलब्ध होता है, और क्लाइंट प्रतिक्रिया प्राप्त करने के तुरंत बाद एक नया अनुरोध भेजता है।

Swift में async/await के साथ Long Polling का उदाहरण

import Foundation\n\nclass LongPollingClient {\n    private let session: URLSession\n    private let baseURL = URL(string: "https://api.pythonlib.ru/events")!\n    private var isPolling = false\n    \n    init() {\n        let config = URLSessionConfiguration.default\n        config.timeoutIntervalForRequest = 60 // लंबा टाइमआउट\n        config.waitsForConnectivity = true\n        self.session = URLSession(configuration: config)\n    }\n    \n    func startPolling() async {\n        isPolling = true\n        while isPolling {\n            do {\n                let (data, response) = try await session.data(from: baseURL)\n                guard let httpResponse = response as? HTTPURLResponse,\n                      httpResponse.statusCode == 200 else {\n                    continue\n                }\n                // प्राप्त डेटा को संसाधित करना\n                if let events = try? JSONDecoder().decode([Event].self, from: data) {\n                    await handleEvents(events)\n                }\n            } catch {\n                // यदि टाइमआउट है — बस एक नया चक्र शुरू करें\n                if let urlError = error as? URLError, \n                   urlError.code == .timedOut {\n                    continue\n                }\n                // अन्य त्रुटियाँ — लॉग करें और प्रतीक्षा करें\n                print("Polling error: \\(error.localizedDescription)")\n                try? await Task.sleep(nanoseconds: 5_000_000_000)\n            }\n        }\n    }\n    \n    func stopPolling() {\n        isPolling = false\n    }\n    \n    private func handleEvents(_ events: [Event]) async {\n        // मुख्य थ्रेड पर UI अपडेट करें\n        await MainActor.run {\n            NotificationCenter.default.post(name: .newEvents, object: events)\n        }\n    }\n}

महत्वपूर्ण: त्रुटियों के मामले में Task.sleep का उपयोग करना न भूलें, ताकि सर्वर पर अंतहीन पुन: कनेक्शन का स्पैम न हो। pythonlib.ru पर, हमने 10k क्लाइंट के लोड पर इस दृष्टिकोण का परीक्षण किया — सर्वर अच्छी तरह से संभालता है, लेकिन विलंबता बढ़ जाती है।

Swift में WebSocket: मूल शक्ति या Starscream?

iOS 13 से, Apple ने URLSessionWebSocketTask के माध्यम से WebSocket के लिए मूल समर्थन जोड़ा। इसका मतलब है कि आप तृतीय-पक्ष लाइब्रेरीज़ के बारे में भूल सकते हैं, हालाँकि Starscream उन परियोजनाओं के लिए एक लोकप्रिय विकल्प बना हुआ है जिन्हें पुराने iOS (12 और उससे नीचे) के समर्थन की आवश्यकता है।

Swift पर मूल WebSocket का उदाहरण (iOS 13+)

import Foundation\n\nclass WebSocketManager: NSObject, URLSessionWebSocketDelegate {\n    private var webSocket: URLSessionWebSocketTask?\n    private let session: URLSession\n    \n    override init() {\n        let config = URLSessionConfiguration.default\n        config.timeoutIntervalForRequest = 60\n        self.session = URLSession(configuration: config)\n