मुझे जावा लैंग में शुद्ध सॉकेट का उपयोग कर क्लाइंट/सर्वर इंस्टेंट मैसेंजर को कार्यान्वित करने की आवश्यकता है।
सर्वर को बड़ी संख्या में ग्राहकों की सेवा करनी चाहिए और मुझे यह तय करने की आवश्यकता है कि मैं किस सॉकेट का उपयोग करूँ - टीसीपी या यूडीपी।
धन्यवाद, कोस्टा।तत्काल मैसेंजर टीसीपी या यूडीपी के लिए बेहतर क्या है?
टीसीपी
कारण:
टीसीपी: "। वहाँ पूर्ण गारंटी नहीं है कि डेटा स्थानांतरित बरकरार रहता है और उसी क्रम में इसे भेजा गया था में आता है कि"
यूडीपी: "इस बात की कोई गारंटी नहीं है कि भेजे गए संदेश या पैकेट बिलकुल पहुंच जाएंगे।" http://www.diffen.com/difference/TCP_vs_UDP
आप अपने चैट संदेश चाहते हैं संभवतः खो दिया:
में और अधिक जानें?
संपादित करें: मुझे "बड़े चैट कार्यक्रम" के बारे में हिस्सा याद आया। मुझे लगता है कि चैट प्रोग्राम की प्रकृति के कारण इसे एक टीसीपी सर्वर होना चाहिए, मैं यूडीपी प्रोटोकॉल पर उपयोगकर्ताओं द्वारा भेजी गई वास्तविक पाठ सामग्री की कल्पना नहीं कर सकता।
टीसीपी सर्वरों की अधिकतम सीमा एक ही समय में 65536 कनेक्शन है। यदि आपको वास्तव में उस नंबर से पहले जाना है तो आप एक प्रेषक सर्वर बना सकते हैं जो वर्तमान सर्वर लोड के आधार पर उचित सर्वर पर आने वाले कनेक्ट भेज देगा।
असल में मैं नहीं चाहता कि संदेश खो जाएगा, लेकिन क्या सर्वर बना सकता है सॉकेट की कोई सीमा है? जैसा कि मैं समझता हूं कि प्रत्येक कनेक्ट किए गए टीसीपी क्लाइंट के लिए टीसीपी सॉकेट खोलता है। – Wizit
मैं आपके सर्वर पर लोड सीमाओं के बारे में चिंतित नहीं हूं जबतक कि आप हास्यास्पद बड़े चैट प्रोग्राम को लागू करने की योजना नहीं बनाते। एक टीसीपी सर्वर पर अधिकतम सीमा 65536 कनेक्शन है। और हाँ, आपको प्रत्येक ग्राहक के लिए एक खुला कनेक्शन होना है। –
यह इस बात पर निर्भर करता है कि उपयोगकर्ता को यह पता होना चाहिए कि संदेश सर्वर पर दिए गए हैं या नहीं। यूडीपी पैकेट में कोई अंतर्निहित पावती नहीं है। यदि ग्राहक सर्वर पर आईएम संदेश भेजता है और यह पारगमन में खो जाता है, न तो क्लाइंट या सर्वर इसके बारे में जानेंगे।
(संक्षिप्त उत्तर "उपयोग टीसीपी" है ... लेकिन यह अपने आप के लिए डिजाइन निहितार्थ के माध्यम से सोच के लायक है।)
टीसीपी आप विश्वसनीयता, जो जब त्वरित संदेश के दौरान निश्चित रूप से वांछनीय है देना होगा - आप कनवर्टेशन के दौरान संदेश नहीं छोड़ेगा।
हालांकि, यदि आप समूह संदेश का उपयोग करना चाहते हैं, तो आप mulitcast का उपयोग कर समाप्त कर सकते हैं। ऐसे मामलों के लिए, यूडीपी सही चोटी होगी क्योंकि यूडीपी मल्टीपॉइंट को इंगित कर सकता है। मल्टीकास्ट अनुप्रयोगों के लिए टीसीपी का उपयोग करना कठिन होगा क्योंकि अब प्रेषक को कई रिसीवरों के लिए रीट्रांसमिशन/भेजने की दर का ट्रैक रखना होगा। पॉइंट-टू-पॉइंट चैट के लिए टीसीपी का उपयोग करने और समूह मैसेजिंग के लिए यूडीपी का उपयोग करने का एक विकल्प हो सकता है।
आप दोनों का उपयोग कर सकते हैं। वास्तविक संदेशों का आदान-प्रदान करने के लिए टीसीपी का उपयोग करें, (इसलिए कोई डेटा खो गया है और बड़े संदेशों को स्ट्रीम कर रहा है, (उदाहरण के लिए जेपीईजी इत्यादि), संभव है। केवल यूडीपी का उपयोग उन ग्राहकों को संक्षिप्त 'कनेक्ट नोव' संदेश भेजने के लिए करें जिनके लिए संदेश कतारबद्ध हैं। ग्राहक राज्य संक्रमणों के साथ-साथ सामान्य संदेश-विनिमय घटनाओं को नियंत्रित करने के लिए विभिन्न टाइमआउट के साथ (NotLoggedIn, TCPconnected, TCPdisconnected, LoggedOut) जैसे राज्य हो सकते हैं। यूडीपी 'कनेक्ट नाउ' संदेश क्लाइंट को 'टीसीपीडीकनेक्टेड' कनेक्ट करने के लिए निर्देश देगा और इसलिए आगे बढ़ें 'टीसीपीकनेक्टेड', जहां वे रहते हैं, संदेशों का आदान-प्रदान करते हैं, जब तक कि कुछ निष्क्रियता टाइमर क्लाइंट को डिस्कनेक्ट करने के लिए निर्देशित नहीं करता है। यह निश्चित रूप से अविश्वसनीय होगा और इसलिए आप एन एक्स के लिए प्रत्येक एक्स सेकेंड 'कनेक्ट नोव' संदेश दोहराना चाहेंगे जब तक क्लाइंट कनेक्ट नहीं हो जाता है। ग्राहक को, किसी भी मामले में, हर एक्स मिनट में मतदान का प्रयास करना चाहिए, बस ...
यह निर्भर करता है कि आपका रिक uirements हैं।आपको केवल एक ही आवश्यकता है, "बड़ी संख्या में ग्राहक" मूल रूप से व्यर्थ है क्योंकि हम नहीं जानते कि क्या आप 800 ग्राहकों को "बड़ी संख्या" या 16,000 मानते हैं। –
यह एक ही समय में हजारों क्लाइंट हो सकता है – Wizit