चैट सेवा बनाना उतना आसान नहीं है जितना आप सोचते हैं।
मैंने पूर्ण एक्सएमपीपी सर्वर, क्लाइंट और एसडीके का निर्माण किया है और कुछ सूक्ष्म और कठिन समस्याओं की पुष्टि कर सकता हूं जो उत्पन्न होती हैं। एक प्रोटोटाइप जहां उपयोगकर्ता एक दूसरे को देखते हैं और चैट करना आसान है। खाता निर्माण, सुरक्षा, खोज, उपस्थिति, ऑफ़लाइन वितरण और मित्र सूची के साथ एक पूर्ण सुविधा प्रणाली एक चुनौती से कहीं अधिक है। तब पैमाने पर सर्वरों की एक मनमानी संख्या में विशेष रूप से कठिन है।
PubSub एक चैट सेवा के निर्माण के पारंपरिक साधनों के बजाय चैट सेवाओं (देखें XEP-60) द्वारा प्रदान की जाने वाली एक विशेषता है। मैं आकर्षण देख सकता हूं, लेकिन पबसुब में कमियां हो सकती हैं।
आपके लिए कुछ प्रश्न:
-
क्या आप इसे वेब पर कर रहे हैं? क्या उपयोगकर्ता कनेक्ट होने और लंबे समय तक मतदान करने वाले हैं या क्या आपके पास वेब सॉकेट समाधान है?
-
कितने उपयोगकर्ता? प्रति उपयोगकर्ता कितने कनेक्शन? पढ़ने के लिए लिखने का अनुपात?
-
इस तरह से SQS का उपयोग करने का आपका विचार दिलचस्प है, लेकिन शायद यह पैमाना नहीं होगा। किसी चैट सर्वर पर 50 हजार या अधिक उपयोगकर्ता होना कोई असामान्य बात नहीं है। यदि आप प्रत्येक उपयोगकर्ता के लिए प्रत्येक एसक्यूएस कतार मतदान कर रहे हैं तो आप उसके पास कहीं भी नहीं जा रहे हैं। आप प्रत्येक सर्वर के लिए कतार रखने से बेहतर होंगे, और सर्वर केवल उस कतार का चुनाव करेगा। फिर यह आप पर निर्भर करता है कि उपयोगकर्ता किस सर्वर पर है और संदेश को सही कतार में रखें।
मुझे संदेह है कि आप कुछ इस तरह जाना चाहेंगे:
- बैकएंड पर एक बड़ा RDS डेटाबेस।
- क्लाइंट कनेक्शन को संभालने वाले फ्रंट-एंड सर्वरों का एक समूह।
- कुछ मध्य स्तरीय जावा / सी# कोड सब कुछ ट्रैक कर रहा है और संदेशों को सही जगह पर रूट कर रहा है।
चैट सर्वर बनाने की जटिलता का अंदाजा लगाने के लिए XMPP RFC's:RFC 3920RFC 3921
पढ़ें।
