मैं मल्टीकास्ट तकनीक, या अन्यथा यूडीपी मल्टीकास्ट के साथ थोड़ा अनुभव साझा करना चाहता हूं, और समस्या एक विशेषता है जो क्रॉस-प्लेटफ़ॉर्म कोड लिखते समय होती है।


तुरंत एक आरक्षण करें कि यह लेख स्वयं प्रौद्योगिकी और यूडीपी प्रोटोकॉल पर विचार नहीं करेगा, इसके लिए यूडीपी की ओर मुड़ना बेहतर है, और फिर मल्टीकास्ट के लिए ।

तो, सभी काम सॉकेट के निर्माण और उसके "कॉन्फ़िगरेशन" से शुरू होते हैं। सामान्य शब्दों में यह ऐसा दिखता है
1. एक सॉकेट बनाएं
2. बांधना
3. मल्टीकास्ट समूह के साथ जुड़ें।

अब क्रम में

सॉकेट निर्माण

सब कुछ सरल और बिना चाल के है।

sockfd = socket(AF_INET, SOCK_DGRAM, 0); 

सॉकेट बाइंडिंग

पहली चीज जो हमें करने की आवश्यकता है वह है PORT को पुन: उपयोग करने की अनुमति देना, जैसा कि हमारे अलावा, कोई और इस पोर्ट के साथ काम कर सकता है।

 const int optval = 1; setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval)); 

सेटस्कॉकटॉप फ़ंक्शन आपको सॉकेट के लिए विकल्प सेट करने की अनुमति देता है। एक दिलचस्प बिंदु यह है कि विकल्प मान को पॉइंटर से शून्य में पारित किया जाता है, क्योंकि कुछ विकल्पों के लिए न केवल ऑन / ऑफ फ्लैग की आवश्यकता होती है, बल्कि अतिरिक्त डेटा वाली संरचनाएं भी होती हैं।
इसके बाद, हमें सॉकेट को पोर्ट से कनेक्ट करना होगा। या शायद एक पता? यहां पहला फीचर फीचर आता है - विंडोज और लिनक्स गुठली की अलग विचारधारा। अर्थात्, विंडोज के तहत हम मल्टीकास्ट समूह के पते पर नहीं बंध सकते (हमें एक त्रुटि मिलती है) और INADDR_ANY से बंधना चाहिए

 struct sockaddr_in addr; bzero(&addr, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(port); addr.sin_addr.s_addr = htonl(INADDR_ANY); bind(sockfd, (sockaddr *)&addr, sizeof(addr)); 

लिनक्स पर, हम INADDR_ANY से भी बंध सकते हैं, लेकिन इस मामले में हम उन सभी डाटाग्राम को प्राप्त करेंगे जो हमारे द्वारा बाँधे गए पोर्ट पर आए थे। केवल वांछित समूह से डेटाग्राम प्राप्त करने के लिए, इस समूह के पते पर (या, निश्चित रूप से, पोर्ट को मत भूलना) आवश्यक है।

समूह कनेक्शन

मल्टीकास्ट की मुख्य विशेषता यह है कि जब तक हम मल्टीकास्ट समूह से कनेक्ट नहीं करेंगे, तब तक हमारे मेजबान को डेटा प्राप्त नहीं होगा। एक उपयोगकर्ता स्तर कनेक्शन सॉकेट के लिए एक विकल्प सेट करने जैसा दिखता है।

 struct ip_mreq mreq; inet_aton(ip_addr, &(mreq.imr_multiaddr)); mreq.imr_interface.s_addr = htonl(INADDR_ANY); setsockopt(sockfd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq)); 

जहाँ ip_mreq.imr_multiaddr मल्टीकास्ट समूह का पता है। और ip_mreq.imr_interface उस इंटरफ़ेस का पता है जिस पर हम डेटाग्राम प्राप्त करने की उम्मीद करते हैं। इस मामले में INADDR_ANY इंगित करता है कि हम इस अधिकार को कर्नेल पर छोड़ देते हैं, जो रूटिंग टेबल के आधार पर इंटरफ़ेस का चयन करेगा। अगला, कर्नेल यह जांच करेगा कि क्या हम पहले से ही इस समूह से जुड़े हैं, और यदि नहीं, तो यह निकटतम मल्टीकास्ट सर्वर को एक अनुरोध भेजेगा। कि आगे की ओर, आदि। उसके बाद, इस मल्टीकास्ट समूह को भेजे गए डेटाग्राम हमारे मेजबान को भेजे जाएंगे।

लेकिन विंडोज के साथ क्या करना है जो INADDR_ANY से जुड़ा हुआ है? वह सभी डेटाग्राम को सुनने के बंदरगाह पर क्या प्राप्त करेगा? जाहिरा तौर पर, विंडोज कर्नेल, सॉकेट के लिए इस विकल्प को निर्दिष्ट करते समय, स्वयं प्राप्त डेटा को फ़िल्टर करता है। और इस प्रकार केवल हस्ताक्षरित समूहों के डेटा को सॉकेट तक पहुंचाया जाता है।

लिनक्स पर, एक जुड़े हुए मल्टीकास्ट समूह से केवल एक सॉकेट पर डेटा प्राप्त करने के लिए, अपने स्वयं के पते पर बांधना आवश्यक है।

यदि आप मुझ पर विश्वास नहीं करते हैं (और मैं खुद शुरुआत में यह नहीं मानता) तो उस पर विश्वास करें

यूनिक्स नेटवर्क प्रोग्रामिंग 3 संस्करण। अध्याय 21.6 पृष्ठ 599
- मल्टीकास्ट डेटाग्राम प्राप्त करने के लिए, प्रक्रिया को समूह में शामिल होना चाहिए और पोर्ट नंबर के साथ यूडीपी सॉकेट को भी बांधना चाहिए, जिसका उपयोग इस समूह को भेजे गए डेटाग्राम के लिए प्राप्तकर्ता के पोर्ट नंबर के रूप में किया जाएगा।
...
पोर्ट कनेक्ट करके, एप्लिकेशन यूडीपी को इंगित करता है कि इस पोर्ट पर भेजे गए डेटाग्राम को प्राप्त करना आवश्यक है। पोर्ट बाइंडिंग के अतिरिक्त कुछ एप्लिकेशन, बाइंड फ़ंक्शन का उपयोग करके एक सॉकेट में मल्टीकास्ट एड्रेस को भी बांधते हैं। यह सॉकेट को इस पोर्ट के लिए प्राप्त होने वाले किसी भी अन्य डेटाग्राम को वितरित करने से रोकता है।

बूस्ट के बारे में क्या?

मैं आपको निराश करूंगा, सब कुछ एपीआई के समान है, एक भी तर्क के लिए कोई अनुकूलन नहीं किया जाता है। इस प्रकार, क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन लिखने के लिए इसका उपयोग करते हुए, आपको अभी भी करना है

 #ifdef WIN32 boost::asio::ip::udp::endpoint listen_endpoint("0.0.0.0", multicast_port); #else boost::asio::ip::udp::endpoint listen_endpoint(multicast_address, multicast_port); #endif socket_.open(listen_endpoint.protocol()); socket_.set_option(boost::asio::ip::udp::socket::reuse_address(true)); socket_.bind(listen_endpoint); ocket_.set_option(boost::asio::ip::multicast::join_group(multicast_address)); 

एक सॉकेट के लिए कई समूह

पोस्ट लिखते समय मैंने महसूस किया कि लिनक्स के लिए प्रस्तावित पथ एक सीमा को छुपाता है। हमें एक सॉकेट के सिद्धांत पर काम करना चाहिए - एक मल्टीकास्ट समूह। चूंकि एक ही बार में कई पतों को बांधना मुश्किल है।

मैं स्थिति को रेखांकित करूंगा। एक सर्वर है, यह कई मल्टीकास्ट समूहों में डेटा को एक पोर्ट पर प्रसारित करता है।

एक ग्राहक है, वह केवल कुछ समूहों में सर्वर से डेटा प्राप्त करना चाहता है। फिर उसे निम्नलिखित क्रियाएं करने की आवश्यकता है:

1. INADDR_ANY पर बांधने के लिए
2. अगला, अपने गंतव्य ¹ पते को निर्धारित करके मैन्युअल रूप से प्राप्त सभी डेटाग्राम को फ़िल्टर करें।

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

ठीक है, वास्तव में मल्टीकास्ट के साथ काम करने की शांत विशेषताओं के बारे में, मैं आपको बताना चाहता था, बिना यह जाने कि आप जोखिम किस कदम पर उठा रहे हैं।

पुनश्च। यह सब महसूस करने के लिए, मैं निम्नलिखित चरणों का प्रस्ताव करता हूं।
1. रिसीवर एकत्रित करें
2. प्रेषक बनाएँ
लिनक्स रन पर अगला
3. रन: रिसीवर 0.0.0.0 239.192.100.1
4. रन: रिसीवर 0.0.0.0 239.192.100.2
5. रन: प्रेषक 239.192.100.1
6. यह समझाने के लिए कि दोनों रिसीवर डेटा प्राप्त करेंगे
अगला, विंडोज पर भी चलता है
7. सुनिश्चित करें कि केवल एक जिसे हमने भेजा है वह डेटा प्राप्त करेगा।

---

¹ यूडीपी की एक अन्य विशेषता यह है कि प्रेषक और रिसीवर का पता स्पष्ट रूप से यूडीपी संदेश के हेडर में नहीं दर्शाया गया है। लेकिन कैलेंडरों की गणना करते समय इसे ध्यान में रखा जाता है, इस प्रकार, एक यूडीपी डेटाग्राम प्राप्त करते हुए, मॉड्यूल को अपने छद्म हेडर की रचना करनी चाहिए, सेकुम की गणना करें और प्राप्त एक के साथ तुलना करें, तय करें कि डेटाग्राम हमें संबोधित किया गया था। जाहिर है, लिनक्स यह जांच करता है कि हम उस पते का उपयोग करते हैं जिसे हम गंतव्य के रूप में बाँधते हैं, यही कारण है कि हमें ऊपर वर्णित समस्या मिलती है।