एक मिलियन एक साथ टीसीपी कनेक्शन कैसे बनाए रखें?

Question

मैं ऐसे सर्वर को डिज़ाइन करना चाहता हूं, जो के साथ-साथ सर्वर से कनेक्ट होने वाले लाखों क्लाइंटों को टीसीपी के माध्यम से कनेक्ट करने की आवश्यकता है।

सर्वर और क्लाइंट के बीच डेटा यातायात दुर्लभ होगा, इसलिए बैंडविड्थ मुद्दों को अनदेखा किया जा सकता है।

एक महत्वपूर्ण आवश्यकता यह है कि जब भी सर्वर को किसी भी ग्राहक को डेटा भेजने की आवश्यकता होती है तो उसे क्लाइंट की ओर एक नया कनेक्शन खोलने के बजाय मौजूदा टीसीपी कनेक्शन का उपयोग करना चाहिए (क्योंकि क्लाइंट फ़ायरवॉल के पीछे हो सकता है)।

क्या कोई जानता है कि यह कैसे करें, और किस हार्डवेयर/सॉफ़्टवेयर की आवश्यकता है (कम से कम लागत पर)?

Answer 1

इसके लिए आप किस ऑपरेटिंग सिस्टम पर विचार कर रहे हैं?

यदि Windows OS का उपयोग करना और Vista से बाद में कुछ उपयोग करना है तो आपको एक मशीन पर हजारों कनेक्शनों के साथ कोई समस्या नहीं होनी चाहिए। मैंने परीक्षण चलाया है (यहां: http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html) कम स्पेक विंडोज सर्वर 2003 मशीन के साथ और आसानी से 70,000 से अधिक सक्रिय टीसीपी कनेक्शन प्राप्त किए। संभवतः कनेक्शन की संख्या को प्रभावित करने वाली कुछ संसाधन सीमाएं Vista पर काफी हद तक हटा दी गई हैं (यहां देखें: http://www.lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html) और इसलिए आप संभवतः मशीनों के एक छोटे समूह के साथ अपना लक्ष्य प्राप्त कर सकते हैं। मुझे नहीं पता कि कनेक्शन के मार्ग के लिए आपको उनके सामने क्या चाहिए।

विंडोज एक सुविधा बुलाया प्रदान करता है मैं/हे समापन बंदरगाहों (देखें: http://msdn.microsoft.com/en-us/magazine/cc302334.aspx) जो आप 5000 कनेक्शन 2 के साथ एक सर्वर के लिए एक लिंक को संतृप्त के साथ बहुत कुछ धागे के साथ समवर्ती कनेक्शन की कई हजारों की सेवा के लिए (मैं परीक्षण चल रहा था कल की अनुमति देते हैं I/O को संसाधित करने के लिए धागे ...)। इस प्रकार बुनियादी वास्तुकला बहुत स्केलेबल है।

आप कुछ परीक्षण तो चलाना चाहते हैं तो मुझे लगता है कि आप कनेक्शन के कई हजारों का उपयोग कर एक सरल गूंज सर्वर (1) और (2) और जो आप इस्तेमाल कर सकते हैं कुछ मुफ्त कोड पिटाई करने की अनुमति अपने ब्लॉग पर कुछ स्वतंत्र रूप से उपलब्ध उपकरण है आपको शुरू करने के लिए (3)

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

और याद रखें, अपनी समस्याओं केवल सिर्फ एक बार आप अपने सिस्टम इस स्तर तक पैमाने पर करने के मिल शुरुआत कर रहे हैं ...

Answer 2

यह समस्या तथाकथित C10K समस्या से संबंधित है। जब आप हजारों क्लाइंटों को एक ही सर्वर से कनेक्ट करने की अनुमति देने का प्रयास करते हैं तो उन समस्याओं को हल करने के लिए C10K पृष्ठ में बड़ी संख्या में अच्छे संसाधन सूचीबद्ध होते हैं।

Answer 3

संपादित करें: जैसा कि नीचे टिप्पणी में बताया गया है, अपने मूल दावे एक 64K बंदरगाहों की संख्या के आधार सीमा नहीं है कि वह सही नहीं है, लेकिन वहाँ सॉकेट की संख्या पर एक 32K सीमा संभालती है, इसलिए मेरी सुझाया गया डिजाइन मान्य है।

एक विशिष्ट टीसीपी/आईपी सर्वर डिज़ाइन के साथ, आप एक साथ खुले कनेक्शन की संख्या में सीमित हैं। सर्वर में एक सुनना बंदरगाह होता है, और जब कोई क्लाइंट उससे कनेक्ट होता है तो सर्वर एक स्वीकार्य कॉल करता है, और यह शेष कनेक्शन के लिए एक यादृच्छिक बंदरगाह पर एक नई सॉकेट बनाता है।

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

इस दृष्टिकोण के साथ, आपकी एकमात्र सीमा यह है कि आप कितनी जल्दी यूडीपी संदेशों को संभालने और जवाब दे सकते हैं। लाखों ग्राहकों के साथ, यहां तक ​​कि दुर्लभ ट्रैफिक आपको बड़ी स्पाइक्स दे सकता है, और यदि आप पैकेट को पर्याप्त तेज़ी से नहीं पढ़ते हैं तो आपकी इनपुट कतार भर जाएगी और आप पैकेट छोड़ना शुरू कर देंगे। सी 10 के पेज ग्रेग अंक आपको इसके लिए रणनीतियों देगा।

Answer 4

मैं कुछ समय पहले APE Project पर आया हूं। ऐसा लगता है कि एक सपने सच हो गया है। वे एक एकल नोड पर 100k समवर्ती ग्राहकों का समर्थन कर सकते हैं। उन्हें 10 या 20 नोड्स में फैलाएं, और आप लाखों की सेवा कर सकते हैं। रीस्टफुल अनुप्रयोगों के लिए बिल्कुल सही। किसी भी साझा नामस्थान के लिए गहराई से देखना चाहते हैं। एक दोष यह है कि यह एक स्टैंडअलोन सर्वर है, जैसा कि वेब सर्वर के पूरक में है। यह सर्वर निश्चित रूप से ओपन सोर्स है, इसलिए कोई भी लागत हार्डवेयर/आईएसपी संबंधित है।

Answer 5

आप यूडीपी उपयोग नहीं कर सकते। यदि ग्राहक अनुरोध भेजता है और आप तुरंत जवाब नहीं देते हैं, तो राउटर 30 सेकंड या उससे कम समय में रिवर्स रूट को भूलने जा रहा है, इसलिए आपका सर्वर कभी भी ग्राहक को जवाब देने में सक्षम नहीं होगा।

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

मैं यह देखने के लिए "स्नफ़फर" स्थापित करने की सलाह देता हूं कि यह देखने के लिए कि फ़ोन कंपनियां अपने "पुश" तकनीक के लिए अपने स्मार्टफ़ोन के संपर्क में कैसे रह रही हैं। जो कुछ भी कर रहे हैं उसकी प्रतिलिपि बनाएँ, क्योंकि वह सामान काम करता है!

Answer 6

के रूप में ग्रेग उल्लेख किया है, समस्या आप का वर्णन कर रहे हैं मैं हाल ही में है कि मापता है लिनक्स पर एक सरल टीसीपी गूंज सर्वर बहुत अच्छी तरह से साथ सत्र की संख्या बनाया C10K (या बल्कि "C1M" अपने मामले में) है (केवल अप करने के लिए परीक्षण किया 200.000 हालांकि), epoll कतार का उपयोग करके। बीएसडी पर, आपके पास कुछ ऐसा ही है जिसे क्यूक्यू कहा जाता है। यदि आप चाहें तो code देख सकते हैं। उम्मीद है इससे मदद मिलेगी और सौभाग्यशाली हो!