🙎🏿 🤛🏻 🚒 यूडीपी और प्रतिक्रिया वितरण समस्या 🏓 👠 👩‍👩‍👦‍👦

नीचे नेटवर्क अनुप्रयोगों में udp के साथ काम करने की समस्या के बारे में एक लेख का अनुवाद है। अनुवादक ने खुद को उदाहरण बदलने की अनुमति दी: स्रोत पाठ में, अन्य नेटवर्क पते और रूबी कोड। अनुवाद ने मोती पर एक सरल लिपि का उपयोग किया। समस्या का सार और इससे समाधान नहीं बदलता है।
इसके अलावा, मेरी टिप्पणियाँ स्थानों में (कोष्ठक में, इटैलिक में) जोड़ी गईं।
ध्यान आकर्षित करने के लिए चित्र अद्भुत पुस्तक " learnyousomeerlang.com " के पाठ से लिया गया है।

हल्के प्रोटोकॉल की कड़ी मेहनत

कभी-कभी ऐसा लगने लगता है कि संबंध स्थापित किए बिना प्रोटोकॉल उस पूरी गड़बड़ी को सही नहीं ठहराते जो वे पैदा करते हैं।

एक उदाहरण के रूप में, उस स्थिति का विश्लेषण करें जब एक प्रतिक्रिया प्राप्त होती है जब एक प्रारंभिक अनुरोध वाला यूडीपी डेटाग्राम इंटरफ़ेस (उर्फ या माध्यमिक आईपी) पर एक अतिरिक्त आईपी पते पर भेजा जाता है।
एक eth1 इंटरफ़ेस है:

$ ip a add 192.168.1.235/24 dev eth1 && ip a ls dev eth1 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:30:84:9e:95:60 brd ff:ff:ff:ff:ff:ff inet 192.168.1.47/24 brd 192.168.1.255 scope global eth1 inet 192.168.1.235/24 scope global secondary eth1 inet6 fe80::230:84ff:fe9e:9560/64 scope link valid_lft forever preferred_lft forever

आमतौर पर udp द्वारा पैकेज प्राप्त करने के लिए कोड कैसा दिखता है? अच्छी तरह से, गूंज सर्वर बिल्ली के नीचे एक की तरह लग सकता है:

echo_server.pl

 #!/usr/bin/perl use IO::Socket::INET; # flush after every write $| = 1; my ($socket,$received_data); my ($peeraddress,$peerport); $socket = new IO::Socket::INET ( MultiHomed => '1', LocalAddr => $ARGV[0], LocalPort => defined ($ARGV[1])?$ARGV[1]:'5000', Proto => 'udp' ) or die "ERROR in Socket Creation : $! \n"; print "Waiting for data..."; while(1) { $socket->recv($recieved_data,1024); $peer_address = $socket->peerhost(); $peer_port = $socket->peerport(); chomp($recieved_data); print "\n($peer_address , $peer_port) said : $recieved_data"; #send the data to the client at which the read/write operations done recently. $data = "echo: $recieved_data\n"; $socket->send("$data"); } $socket->close();

यह एक काफी सरल मोती स्क्रिप्ट है जो यह दिखाएगा कि udp पैकेट किससे आया है, पैकेट की सामग्री है, और पैकेट को प्रेषक को वापस भेज देता है। कहीं भी आसान नहीं है। अब हमारा सर्वर चलाएं:

 $ ./echo_server.pl Waiting for data...

आइए देखें कि वह क्या सुनता है:

 $ netstat -unpl | grep perl udp 0 0 0.0.0.0:5000 0.0.0.0:* 9509/perl

और उसके बाद, प्राथमिक आईपी के माध्यम से रिमोट मशीन से हमारे सर्वर से कनेक्ट करें:

 -bash-3.2$ nc -u 192.168.1.47 5000 test1 echo: test1 test2 echo: test2

यह हमारी मशीन पर tcpdump में कैसे दिखता है (अच्छी तरह से, या इसे देखना चाहिए):

 -bash-3.2$ tcpdump -i eth1 -nn port 5000 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 17:41:00.517186 IP 192.168.3.11.44199 > 192.168.1.47.5000: UDP, length 6 17:41:00.517351 IP 192.168.1.47.5000 > 192.168.3.11.44199: UDP, length 12 17:41:02.307634 IP 192.168.3.11.44199 > 192.168.1.47.5000: UDP, length 6 17:41:02.307773 IP 192.168.1.47.5000 > 192.168.3.11.44199: UDP, length 12

बस शानदार - मैं पैकेज भेजता हूं और पैकेज वापस लेता हूं। नेटकैट में, हमें कोई फर्क नहीं पड़ता कि हम क्या प्रिंट करते हैं (यदि आप "तीर" प्रिंट करते हैं तो एक हास्यास्पद प्रभाव)।

और अब एक ही इंटरफ़ेस पर द्वितीयक पते की बात:

 -bash-3.2$ nc -u 192.168.1.235 5000 test1 test2

इस बार tcpdump में यह पागलपन कैसे दिखता है:

 -bash-3.2$ tcpdump -i eth1 -nn port 5000 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 17:48:32.467167 IP 192.168.3.11.34509 > 192.168.1.235.5000: UDP, length 6 17:48:32.467292 IP 192.168.1.47.5000 > 192.168.3.11.34509: UDP, length 12 17:48:33.667182 IP 192.168.3.11.34509 > 192.168.1.235.5000: UDP, length 6 17:48:33.667332 IP 192.168.1.47.5000 > 192.168.3.11.34509: UDP, length 12

ठीक है, निश्चित रूप से, कोई भी स्वाभिमानी नेटवर्क स्टैक पूरी तरह से अपरिचित पते से पैकेट प्राप्त करने जा रहा है, भले ही पोर्ट सही हों। इस प्रकार, क्लाइंट को कभी भी रिटर्न पैकेट नहीं मिलेगा और यह सोचेगा कि सर्वर केवल अपने अनुरोधों को छोड़ रहा है।

पहली नज़र में जो होता है वह पूरी तरह बकवास लगता है। लेकिन वास्तव में, यह एक सत्र की स्थापना के बिना एक प्रोटोकॉल का एक सामान्य दोष है, जैसे कि यूडीपी। आप देखते हैं, हमारा सॉकेट किसी भी पते पर सुनता है (खाली लोकल एड्रैड पैरामीटर को सिस्टम में "0.0.0.0" पते के रूप में पास किया जाता है, सॉकेट बनाते समय, कोई भी उपलब्ध हो, जो सॉकेट को सभी उपलब्ध पते पर सुनने के लिए बाध्य करता है। और नहीं, मुझे यह भी पता नहीं है कि ऐसा क्यों है। यह एक विशेष रूप से सहज क्रिया नहीं है)। जब हम सॉकेट-> recv () का उपयोग करके अपने आवेदन में एक पैकेट प्राप्त करते हैं, तो हमें यह जानकारी नहीं मिलती है कि पैकेट को किस विशिष्ट पते पर भेजा गया था। हम केवल यह जानते हैं कि ऑपरेटिंग सिस्टम ने फैसला किया कि पैकेज हमारे लिए था (यहां आपके पास इनकैप्सुलेशन है)। हम सभी जानते हैं कि पैकेज कहां से आया है। और इस तथ्य के कारण कि कर्नेल सॉकेट के कनेक्शन के बारे में कोई जानकारी संग्रहीत नहीं करता है (कर्नेल तार्किक है, यह कनेक्शन के बिना पूछा गया था - यह कनेक्शन के बिना होगा), जब पैकेट वापस भेजने का समय आता है, तो हम सभी को बता सकते हैं कि पैकेट को कहां भेजना है। (मोती में, यह अंतर्निहित रूप से किया जाता है। डेटाग्राम के प्रेषक का पता और पोर्ट $ सॉकेट ऑब्जेक्ट के साथ जुड़ा हुआ है, इसलिए आपको इसे कॉल कॉल में निर्दिष्ट करने की आवश्यकता नहीं है)।
लेकिन असली पहेली तब शुरू होती है, जब हम भेजने वाले के पते को प्रतिक्रिया डेटाग्राम में डालने की कोशिश करते हैं। एक बार फिर से: कर्नेल प्रेषक या रिसीवर के बारे में कोई जानकारी संग्रहीत नहीं करता है, क्योंकि हम बिना कनेक्शन के काम करते हैं। और जब से हम "किसी भी" इंटरफ़ेस को सुनते हैं, ऑपरेटिंग सिस्टम को लगता है कि उसके पास उस पते से एक पैकेट भेजने के लिए एक कार्टे ब्लैंच है जिसे वह "पसंद" करता है। लिनक्स में, ऐसा लगता है कि जिस इंटरफ़ेस से पैकेट भेजा जाएगा, उसका मुख्य पता चुना गया है। (दरअसल, पता राउटिंग टेबल - अनुवादक के नोट के अनुसार, पता RFC1122, 3.3.4.2 "मल्टीहोमिंग रिक्वायरमेंट्स" के अनुसार निर्धारित किया जाता है) । तो "एक पते - एक इंटरफ़ेस" के सामान्य मामले के लिए - सब कुछ काम करता है। लेकिन जैसे ही यह कम सामान्य स्थितियों की बात आती है, बारीकियां दिखाई देने लगती हैं।
समाधान सॉकेट्स बनाने के लिए है जो विशिष्ट पते को सुनते हैं। और इन सॉकेट से एक पैकेट भेजें: कर्नेल को पता होगा कि आप किस पते से पैकेट भेजना चाहते हैं और सबकुछ ठीक हो जाएगा। बहुत आसान लग रहा है, है ना? ठीक है, ज़ाहिर है, किसी भी समझदार नेटवर्क अनुप्रयोग पहले से ही है कि, हुह? तो यह स्पष्ट है कि रूबी में यूडीपी कार्यान्वयन केवल बकवास है (मूल में, स्रोत कोड माणिक में है, अनुवादक का नोट;) । यही मैंने शुरू में सोचा था, और यदि आप ऐसा ही सोचते हैं तो मैं आपको दोष नहीं देता। लेकिन जब तक रूबी के यूडीपीएसकेट के लेखकों के साथ युद्ध के रुबिकन को पार नहीं किया गया है, तो आइए अन्य उपयोग किए गए अनुप्रयोगों के साथ थोड़ा प्रयोग करें। उदाहरण के लिए, एसएनएमपीडी। उबंट में नेट-स्नैम्प पैकेज से डेमन उसी समस्या के अधीन है जो हमारे परीक्षण आवेदन के ऊपर है। ऐसा नहीं लगता है कि यह किसी प्रकार की नई रेक है, जिसे उन्होंने अभी-अभी आगे बढ़ाया और फिक्स के लिए पैच के एक गुच्छा के साथ बिखरे हुए हैं।
तो सामान्य तौर पर, हर कोई एक ही "बीमारी" से पीड़ित होता है। "हर कोई" का अर्थ है "कुछ यूडीपी सर्वर।" सॉफ्टवेयर की एक निश्चित मात्रा है जो इंटरफेस पर उपनाम के साथ एक समान समस्या के अधीन नहीं है। बिंद तुरंत दिमाग में आता है और यदि आप सभी इंटरफेस को कॉन्फ़िगर करने के बाद एनटीपी शुरू कर देते हैं तो यह ठीक काम करता है। अंतर क्या है? अंतर यह है कि ये सेवाएँ कुछ हद तक "स्मार्ट" हैं और सिस्टम के सभी पतों को अलग-अलग बाँधती हैं। उदाहरण के लिए, बाँध:

 $ netstat -lun |grep :53 udp 0 0 192.168.1.47:53 0.0.0.0:* udp 0 0 192.168.1.47:53 0.0.0.0:* udp 0 0 127.0.0.1:53 0.0.0.0:*

यह बहुत अच्छा है और समस्या को हल करता है। अपवाद तब होता है जब आप डेमन शुरू होने के बाद एक अतिरिक्त उपनाम जोड़ते हैं। Bind एक नया पता नहीं उठाता है और आपको सर्वर को पुनरारंभ करना होगा। इसके अलावा, यह कोड को थोड़ा जटिल करता है, क्योंकि आपको प्रोग्राम के अंदर सॉकेट्स के एक गुच्छा के साथ मिलना है (उदाहरण के लिए, प्राप्त करने के प्रयास पर इसे अवरुद्ध करने के बजाय चयन () का उपयोग करें।) सामान्य तौर पर, कोई भी अनावश्यक कठिनाइयों को पसंद नहीं करता है, लेकिन आप इसे संभाल सकते हैं। । हालाँकि, असली समस्या "डेमॉन शुरू होने के बाद पते न जोड़ें" नियम है। यह जांचने की आवश्यकता है कि क्या सिस्टम में आईपी पते जोड़े गए हैं और पता जोड़ने के बाद सेवा को फिर से शुरू करना एक वास्तविक समस्या बन जाएगी।
हालाँकि, इस समस्या के लिए कुछ समाधान भी है। यहाँ हम ntpd को याद करते हैं। वह जिन बंदरगाहों को सुनता है वे इस प्रकार हैं:

 $ netstat -nlup | grep 123 udp 0 0 192.168.1.235:123 0.0.0.0:* udp 0 0 192.168.1.47:123 0.0.0.0:* udp 0 0 127.0.0.3:123 0.0.0.0:* udp 0 0 127.0.0.1:123 0.0.0.0:* udp 0 0 0.0.0.0:123 0.0.0.0:* udp6 0 0 fe80::230:84ff:fe9e:123 :::* udp6 0 0 ::1:123

NTPd प्रत्येक पते को व्यक्तिगत रूप से सुनता है और इसके अतिरिक्त सिस्टम पर उपलब्ध किसी भी पते पर सुनता है। मुझे ठीक से नहीं पता कि यह क्यों जरूरी है। यदि आप प्रत्येक पते को अलग से सुनते हैं, तो सब कुछ ठीक हो जाएगा, जैसा कि बाँध के मामले में है। लेकिन अगर आप ntpd शुरू करने के बाद इंटरफ़ेस में एक और पता जोड़ते हैं, तो वही समस्या दिखाई देने लगती है, जैसे कि udp-echo सर्वर के मामले में। इसलिए मुझे नहीं लगता कि "किसी भी" इंटरफ़ेस को सुनने से कोई प्लस मिलता है। हालाँकि, यह ntpd को बिंद से कुछ अलग व्यवहार करता है: जब आप बिंद की शुरुआत के बाद जोड़े गए इंटरफ़ेस पर एक पैकेट भेजते हैं, तो यह बस आपको अनदेखा कर देता है (इसमें एक सॉकेट नहीं है जो आपके अनुरोधों को सुनता है)। Ntpd एक प्रतिक्रिया भेजने की कोशिश करता है और प्रतिक्रियाओं में एक गलत पते की समस्या से ग्रस्त है। (लेकिन आप इंटरफेस पर प्राथमिक पते को बदल सकते हैं और नए इंटरफेस बना सकते हैं, अनुवादक को नोट कर सकते हैं)।

फिलहाल, सबसे अच्छा समाधान यह है कि बिंद और ntpd के मार्ग का अनुसरण करें और ntpd से "फ़ोकस" के साथ अलग-अलग सभी पते सुनें: इसके अलावा 0.0.0.0 तक सुनें। उसी समय, अगर मुझे 0.0.0.0 पर एक पैकेट मिला, तो मुझे सिस्टम में उपलब्ध पते को स्कैन करना शुरू करना होगा और उन्हें अतिरिक्त रूप से बांधना होगा। इससे समस्या का समाधान होना चाहिए।
यह केवल इसे काम करने के लिए बनी हुई है (और समस्याओं का एक गुच्छा हल करें जो संभवतः रास्ते में सामने आएंगे)। मेरी शुभकामनाएं। दर्द और पीड़ा की चीख जो आप सुनते हैं (कोई फर्क नहीं पड़ता कि आप कहां हैं) शायद मेरी हैं।

UPD: टिप्पणी में Quasar_ru से एक दिलचस्प व्याख्या दिखाई दी। सभी समान, स्क्रिप्टिंग भाषाओं में यूडीपी का कार्यान्वयन अस्पष्ट है: शुद्ध सी में, आप एक क्लाइंट एप्लिकेशन लिख सकते हैं जो सर्वर से एक अलग पते से प्रतिक्रिया प्राप्त कर सकता है। ऐसे कार्यान्वयन के लाभ विवादास्पद हैं, लेकिन कार्यान्वयन संभव है।

यूडीपी और प्रतिक्रिया वितरण समस्या

हल्के प्रोटोकॉल की कड़ी मेहनत

More articles: