۲۱. مالتی‌کستینگ (Multicasting)

با نگاهی دوباره به دیاگرام بالا متوجه می‌شویم که آدرس یونیکست (Unicast) به یک Interface منفرد IP اشاره دارد، در حالی که آدرس برودکست (Broadcast) تمامی IPهای موجود در یک زیرشبکه (Subnet) را هدف می‌گیرد و در نهایت، آدرس چندپخشی یا مالتی‌کست (Multicast) به مجموعه‌ای از IP Interfaceها اشاره می‌کند. در واقع Unicast و Broadcast دو قطب کاملاً متضاد در شیوه‌های آدرس‌دهی هستند و Multicast درست در میان این دو قرار می‌گیرد. نکته کلیدی در Multicast این است که دیتاگرام‌ها فقط باید توسط رابط‌هایی دریافت شوند که به آن داده‌ها علاقه دارند؛ به عبارت دیگر، تنها رابط‌های هاست‌هایی باید این ترافیک را دریافت کنند که برنامه‌ای عضو گروه مالتی‌کست (Multicast Group) را اجرا می‌کنند. همچنین برخلاف Broadcast که عموماً به یک شبکه محلی (LAN) محدود می‌شود، Multicast هم در بستر LAN و هم در WAN قابل استفاده است؛ به طوری که امروزه برنامه‌ها به‌طور روزمره بین زیرمجموعه‌های مختلف اینترنت به تبادل داده از طریق مالتی‌کست می‌پردازند.

نکات تکمیلی مربوط به Socket API برای پشتیبانی از Multicasting بسیار ساده و سرراست هستند. این سازوکار در مجموع از ۹ گزینه سوکت (Socket Options) تشکیل شده که ۳ تای آن‌ها به آدرس ارسال دیتاگرام‌های UDP اختصاص دارد و ۶ گزینه دیگر برای مدیریت دریافت دیتاگرام‌ها به کار می‌روند.

آدرس‌های مالتی‌کست (Multicast Addresses)

هنگام بررسی آدرس‌های Multicast، تفکیک میان IPv4 و IPv6 ضروری است.

آدرس‌های IPv4 Class D

در IPv4، آدرس‌های مالتی‌کست تحت عنوان آدرس‌های Class D شناخته می‌شوند و بازه ۲۲۴.۰.۰.۰ تا ۲۳۹.۲۵۵.۲۵۵.۲۵۵ را در بر می‌گیرند. ۲۸ بیت کم‌ارزش‌تر (پایینی) در آدرس‌های Class D به عنوان Multicast Group ID عمل کرده و کل این آدرس ۳۲ بیتی، آدرس گروه (Group Address) نامیده می‌شود.

یادداشت مترجم: از میان ۳۲ بیت، ۴ بیت اول با الگوی ۱۱۱۰ ثابت بوده و ۲۸ بیت باقی‌مانده مورد استفاده قرار می‌گیرد.

تصویر زیر نحوه نگاشت (Mapping) آدرس‌های IP Multicast را به آدرس‌های Ethernet Multicast نشان می‌دهد. روش‌های متعددی برای نگاشت آدرس‌های IPv4 وجود دارد؛ نگاشت روی اترنت در RFC 1112 [Deering 1989]، شبکه‌های FDDI در RFC 1390 [Katz 1993] و شبکه‌های Token Ring در RFC 1469 [Pusateri 1993] تعریف شده‌اند. دیاگرام زیر این نگاشت را بین آدرس‌های IPv4 و Ethernet به تصویر می‌کشد.

در فرایند نگاشت IPv4، ۲۴ بیت پرارزش‌تر (بالایی) آدرس اترنت مالتی‌کست همواره برابر با 01:00:5e است. ۱ بیت بعدی نیز همیشه ۰ بوده و ۲۳ بیت پایینی دقیقاً از ۲۳ بیت کم‌ارزش‌تر آدرس گروه مالتی‌کست کپی می‌شود. ۵ بیت بالاییِ آدرس گروه در طول این فرایند نگاشت نادیده گرفته می‌شود؛ این موضوع بدان معناست که ۳۲ آدرس مالتی‌کست مختلف روی یک آدرس Ethernet یکسان نگاشت می‌شوند؛ بنابراین این یک نگاشت یک‌به‌یک (1:1) نیست.

یادداشت مترجم: به بیان دیگر، نگاشت میان آدرس IPv4 و آدرس اترنت مالتی‌کست به صورت یک‌به‌یک نبوده، بلکه چند آدرس مختلف IPv4 به یک آدرس مشترک اترنت مالتی‌کست نگاشت می‌شوند (نگاشت چندبه‌یک یا N:1).

دو بیت سمت راستِ کم‌ارزش‌تر در اولین بایت آدرس اترنت مشخص می‌کند که این آدرس، یک آدرس گروهیِ مدیریت‌شده به صورت جهانی (universally administered) است. مدیریت جهانی بدین معناست که ۲۴ بیت اول توسط IEEE تخصیص یافته است و در این حالت، اینترفیس گیرنده این آدرس گروهی را به صورت ویژه شناسایی و پردازش می‌کند.

یادداشت مترجم: ۲۴ بیت بالایی در مالتی‌کست روی مقدار ثابت 01:00:5e تنظیم شده است؛ از آنجا که بایت اول برابر با 00000001 در مبنای دودویی است، ۲ بیت پایینی آن 01 خواهد بود که نشان‌دهنده یک آدرس گروهی با مدیریت جهانی است.

در ادامه برخی از آدرس‌های ویژه مالتی‌کست در IPv4 آورده شده است:

• آدرس 224.0.0.1 متعلق به گروه «همه هاست‌ها» (all-hosts) است. تمامی گره‌های دارای قابلیت Multicast در یک زیرشبکه (شامل هاست‌ها، روترها، پرینترها و...) موظفند در تمامی اینترفیس‌های مالتی‌کست خود به عضویت این گروه درآیند (مفهوم عضویت در گروه مالتی‌کست را به‌زودی توضیح خواهیم داد).
• آدرس 224.0.0.2 مربوط به گروه «همه روترها» (all-routers) است. کلیه روترهای فعال در زیرشبکه که قابلیت Multicast دارند، باید روی تمامی اینترفیس‌های مالتی‌کست خود در این گروه عضو شوند.

محدوده ۲۲۴.۰.۰.۰ تا ۲۲۴.۰.۰.۲۵۵ (یا 224.0.0.0/24) با عنوان «لینک-لوکال» (Link-Local) شناخته می‌شود. این آدرس‌ها برای پروتکل‌های نگهداری و کشف توپولوژی در سطح پایین (low-level topology discovery) رزرو شده‌اند و دیتاگرام‌های ارسالی به این مقصدها هرگز نباید توسط روترهای مالتی‌کست به خارج از شبکه محلی فوروارد شوند. پس از بررسی آدرس‌های Multicast در IPv6، جزئیات بیشتری درباره دامنه‌های گوناگون آدرس‌های IPv4 ارائه خواهیم داد.

آدرس‌های مالتی‌کست IPv6

در آدرس‌های مالتی‌کست IPv6، بایت بالایی (پرارزش‌ترین) همواره با ff آغاز می‌شود. همان‌طور که در تصویر بالا مشخص است، آدرس ۱۶ بایتی مالتی‌کست IPv6 به یک آدرس اترنت ۶ بایتی نگاشت می‌شود؛ به این صورت که ۳۲ بیت پایینیِ آدرس گروه مستقیماً در ۳۲ بیت کم‌ارزش‌تر آدرس اترنت کپی می‌شود و ۲ بایت بالاییِ آدرس اترنت نیز مقدار ثابت 33:33 خواهد بود. این نحوه نگاشت روی اترنت در RFC 2464 [Crawford 1998a]، روی شبکه‌های FDDI در RFC 2467 [Crawford 1998b] و روی شبکه‌های Token Ring در RFC 2470 [Crawford, Narten, Thomas 1998] مشخص شده است.

دو بیت پایینیِ بایت اول آدرس اترنت (یادداشت مترجم: ۱۱) نشان‌دهنده یک آدرس گروهی با مدیریت محلی (locally administered) است. مدیریت محلی به این معناست که تضمینی برای یکتا بودنِ این آدرس در بستر IPv6 وجود ندارد. در واقع علاوه بر IPv6، سایر مجموعه‌های پروتکلی (Protocol Suites) که شبکه را به اشتراک گذاشته‌اند نیز ممکن است از همین دو بایت اول در آدرس اترنت استفاده کنند. همان‌گونه که قبلاً اشاره شد، این آدرس‌های گروهی توسط اینترفیس گیرنده به شکل خاصی شناسایی و مدیریت می‌شوند.

یادداشت مترجم: نگاشت اترنت در IPv4 (با پیشوند 01:00:5e) و IPv6 (با پیشوند 33:33) ساختارهای متفاوتی دارند. دلیل این تفاوت با وجود استفاده از آدرس‌های اترنت با ساختار یکسان، فراهم کردن فضای آدرس‌دهی گسترده‌تر در IPv6 است (۲۳ بیت در IPv4 در مقابل ۳۲ بیت در IPv6).

طبق نمودار بالا، آدرس‌های مالتی‌کست IPv6 در دو ساختار کلی ارائه می‌شوند. هنگامی که فلگ P برابر با ۰ باشد، فلگ T به عنوان شاخص تفکیک عمل کرده و گروه‌های شناخته‌شده مالتی‌کست (Well-known با مقدار ۰) را از گروه‌های موقت (Transient با مقدار ۱) متمایز می‌سازد. از سوی دیگر، اگر P برابر با ۱ باشد، نشان‌دهنده آدرس مالتی‌کستی است که بر پایه یک پیشوند یونیکست (Unicast Prefix) تخصیص یافته است. در حالتی که مقدار P برابر ۱ باشد، فلگ T نیز الزاماً باید ۱ باشد؛ به همین علت، آدرس‌های مالتی‌کست مبتنی بر یونیکست همواره ماهیتی موقت (transient) دارند. فیلدهای plen و prefix نیز به ترتیب طول و مقدار پیشوند یونیکست را تعیین می‌کنند، در حالی که ۲ بیت بالاییِ بخش flags رزرو شده است. علاوه بر این، آدرس‌های مالتی‌کست IPv6 شامل یک فیلد ۴ بیتی scope نیز هستند که در ادامه به آن خواهیم پرداخت.

یادداشت مترجم: علت موقتی (transient) بودن همیشگیِ آدرس‌های مالتی‌کستِ مبتنی بر یونیکست این است که آدرس‌های یونیکست بر اساس پیکربندی شبکه ممکن است تغییر کنند.

در ادامه برخی از آدرس‌های ویژه مالتی‌کست در IPv6 آورده شده است:

• آدرس‌های ff01::1 و ff02::1 نمایانگر گروه «همه گره‌ها» در دامنه‌های اینترفیس-لوکال (Interface-Local) و لینک-لوکال (Link-Local) هستند. تمامی گره‌های مستقر در زیرشبکه (از جمله هاست‌ها، روترها و پرینترها) موظفند در تمامی رابط‌های دارای قابلیت مالتی‌کست به عضویت این گروه‌ها درآیند. این سازوکار مشابه آدرس مالتی‌کست 224.0.0.1 در IPv4 است، با این تفاوت که چون مالتی‌کستینگ بخش جدایی‌ناپذیر و الزامی IPv6 به شمار می‌رود، پیوستن به آن کاملاً اجباری است.
• آدرس‌های ff01::2، ff02::2 و ff05::2 به گروه «همه روترها» در دامنه‌های اینترفیس-لوکال، لینک-لوکال و سایت-لوکال (Site-Local) اختصاص دارند. کلیه روترهای زیرشبکه باید روی تمام اینترفیس‌های مالتی‌کست خود عضو این گروه‌ها شوند که این عملکرد معادل آدرس مالتی‌کست 224.0.0.2 در IPv4 است.

یادداشت مترجم: ساختار ff01::1 بدین معناست که پیشوند ff نشان‌دهنده مالتی‌کست، مقدار scope برابر با 01 و کم‌ارزش‌ترین بیت آن برابر با ۱ است.

دامنه و محدوده آدرس‌های مالتی‌کست (Multicast Scope)

در آدرس‌های مالتی‌کست IPv6، یک فیلد ۴ بیتی به نام scope تعبیه شده که مشخص می‌کند یک بسته مالتی‌کست تا چه مسافتی مجاز به انتشار است. بسته‌های IPv6 علاوه بر این، فیلدی تحت عنوان hop limit نیز دارند که تعداد دفعات فوروارد شدن بسته توسط روترها را محدود می‌کند. مقادیر زیر به فیلد scope اختصاص یافته است:

• ۱: interface-local
• ۲: link-local
• ۴: admin-local
• ۵: site-local
• ۸: organization-local
• ۱۴: global

سایر مقادیر یا تخصیص‌نیافته هستند و یا در حالت رزرو قرار دارند. دیتاگرام‌های اینترفیس-لوکال تحت هیچ شرایطی نباید از رابط خارج شوند و دیتاگرام‌های لینک-لوکال نیز نباید از روتر عبور کنند. تعریف دقیق محدوده‌های مدیریتی، سایت یا سازمان بر عهده مدیران روترهای مالتی‌کست همان سازمان است. جالب است بدانید که در IPv6، حتی اگر آدرس‌های مالتی‌کست تنها در فیلد scope با یکدیگر تفاوت داشته باشند، گروه‌های مالتی‌کست کاملاً مجزا و مستقلی در نظر گرفته می‌شوند.

یادداشت مترجم: بنابراین استفاده از دو آدرس مالتی‌کست با Group ID یکسان اما scopeهای متفاوت هیچ تداخلی ایجاد نمی‌کند.

در IPv4 هیچ فیلد scope مجزایی برای بسته‌های مالتی‌کست وجود ندارد؛ از نظر تاریخی، فیلد TTL (Time To Live) در هدر IPv4 هم‌زمان نقش فیلد scope را نیز ایفا می‌کرده است:

• مقدار TTL برابر ۰: اینترفیس-لوکال (interface-local)
• مقدار TTL برابر ۱: لینک-لوکال (link-local)
• مقدار TTL تا ۳۲: سایت-لوکال (site-local)
• مقدار TTL تا ۶۴: منطقه‌ای (region-local)
• مقدار TTL تا ۱۲۸: قاره‌ای (continent-local - صرف‌نظر از بین‌قاره‌ای بودن، از لینک‌های کند یا با ترافیک سنگین اجتناب می‌شود)
• مقدار TTL تا ۲۵۵: بدون محدودیت دامنه (global)

البته این کاربرد دوگانه از فیلد TTL چالش‌ها و دشواری‌های متعددی را به همراه داشته است.

هرچند استفاده از فیلد TTL در IPv4 برای تعیین محدوده به عنوان یک روش پذیرفته‌شده و رایج شناخته می‌شود، اما در صورت امکان بهتر است از تعیین محدوده مدیریتی (Administrative Scoping) استفاده شود. در این روش، بازه ۲۳۹.۰.۰.۰ تا ۲۳۹.۲۵۵.۲۵۵.۲۵۵ به عنوان «فضای مالتی‌کست با مدیریت محدوده در IPv4» (administratively scoped IPv4 multicast space) تعریف شده است.

آدرس‌های واقع در این بازه توسط سازمان‌ها به صورت محلی تخصیص می‌یابند، اما خارج از مرزهای آن سازمان هیچ اعتباری ندارند. بنابراین، روترهای مرزی سازمان (روترهای مالتی‌کست مستقر در لبه شبکه) باید طوری پیکربندی شوند که بسته‌های مالتی‌کست با این آدرس‌های مقصد را هرگز به بیرون هدایت نکنند.

آدرس‌های مالتی‌کست با مدیریت محدوده در IPv4 به دو بخش محدوده محلی (site-local) و محدوده سازمانی-محلی (organization-local) تقسیم می‌شوند. محدوده محلی در اینجا عملکردی شبیه به site-local در IPv6 دارد، اما از نظر مفهومی کاملاً یکسان نیست. قواعد و ساختار این محدوده‌بندی را می‌توانید در تصویر زیر مشاهده کنید.

یادداشت مترجم: با وجود اینکه بازه ۲۳۹.۰.۰.۰ تا ۲۳۹.۲۵۵.۲۵۵.۲۵۵ به عنوان فضای مالتی‌کست با محدوده مدیریتی در IPv4 تعریف می‌شود، در جدول تنها دو بازه ۲۳۹.۱۹۲.۰.۰ تا ۲۳۹.۱۹۵.۲۵۵.۲۵۵ (Organization-local) و ۲۳۹.۲۵۵.۰.۰ تا ۲۳۹.۲۵۵.۲۵۵.۲۵۵ (Site-local) به چشم می‌خورد. بخش‌های باقی‌مانده از این فضا نیز همچنان تحت همین عنوان قرار دارند، اما به کاربرد خاصی اختصاص داده نشده‌اند و سازمان‌ها می‌توانند بر حسب نیاز خود آزادانه از آن‌ها استفاده کنند.

یادداشت مترجم ۲: بر خلاف مفهوم Scope در IPv6، در IPv4 حتی اگر مقادیر TTL متفاوت باشند، در صورت یکسان بودن آدرس Multicast ممکن است پیام‌ها به اشتباه یکسان تلقی شده و مشکلاتی ایجاد شود؛ موضوعی که یکی از مزایای قابل‌توجه IPv6 نسبت به IPv4 به شمار می‌رود.

مقایسه Multicasting و Broadcasting در شبکه LAN

بیایید حالتی را در نظر بگیریم که در آن، یک برنامه فرستنده، دیتاگرام‌های UDP را به آدرس Subnet-directed broadcast یعنی 192.168.42.255 ارسال می‌کند. هرچند این مثال بر پایه IPv4 است، اما ساختار کلی آن در IPv6 نیز شباهت زیادی دارد.

در سمت راست، برنامه دریافت‌کننده روی هاست اجرا می‌شود، یک سوکت UDP ایجاد کرده، پورت 123 را به آن Bind می‌کند و سپس به گروه مالتی‌کست 224.0.1.1 ملحق (Join) می‌شود. این فرآیند Join از طریق فراخوانی تابع setsockopt انجام می‌پذیرد. با این کار، لایه IPv4 این اطلاعات را درون خود ثبت کرده و به لایه Datalink مربوطه دستور می‌دهد تا فریم‌های اترنت ارسال‌شده به آدرس 01:00:5e:00:01:01 را دریافت کند. این آدرس اترنت دقیقا از نگاشتی به دست می‌آید که قبلا توضیح دادیم و معادل آدرس مالتی‌کستی است که برنامه به‌تازگی عضو آن شده است.

مرحله بعد این است که برنامه فرستنده در سمت چپ‌ترین هاست، یک سوکت UDP بسازد و دیتاگرام را به پورت 123 با آدرس 224.0.1.1 بفرستد. برای ارسال یک دیتاگرام مالتی‌کست، نیازی به کار خاص یا عضویت فرستنده در گروه مالتی‌کست نیست. هاست فرستنده آدرس IP مقصد را به آدرس اترنت متناظر تبدیل کرده و فریم را ارسال می‌کند. به خاطر داشته باشید که این فریم، هم شامل آدرس اترنت مقصد (که توسط اینترفیس‌ها بررسی می‌شود) و هم آدرس IP مقصد (که توسط لایه‌های IP بررسی می‌شود) خواهد بود.

حال فرض کنید هاست میانی از IPv4 Multicast پشتیبانی نمی‌کند (چرا که پشتیبانی از مالتی‌کست در IPv4 اختیاری است). این هاست فریم دریافتی را به سه دلیل نادیده می‌گیرد: ۱) آدرس اترنت مقصد با آدرس اینترفیس آن همخوانی ندارد، ۲) آدرس اترنت مقصد یک آدرس Broadcast اترنت نیست، و ۳) به اینترفیس دستوری مبنی بر دریافت بسته‌های آدرس گروه داده نشده است.

از سوی دیگر، لایه Datalink در هاست سمت راست از مکانیزمی تحت عنوان «فیلترینگ ناقص» (Imperfect Filtering) بر روی آدرس اترنت مقصد برای دریافت فریم‌ها استفاده می‌کند. علت اینکه به آن «ناقص» می‌گوییم این است که وقتی به اینترفیس دستور داده می‌شود فریم‌های یک آدرس اترنت مالتی‌کست خاص را دریافت کند، ممکن است به دلایل فنی، فریم‌های مربوط به سایر آدرس‌های مالتی‌کست اترنت را نیز دریافت نماید.

هنگامی که Datalink سمت راست فریم را تحویل می‌گیرد، با توجه به اینکه نوع فریم اترنت از نوع IPv4 است، بسته را به لایه IP تحویل می‌دهد. از آنجا که بسته دریافتی دارای یک آدرس IP مالتی‌کست است، لایه IP این آدرس را با تک‌تک آدرس‌های مالتی‌کستی که برنامه‌های هاست به عضویت آن‌ها درآمده‌اند تطبیق می‌دهد. به این کار «فیلترینگ کامل» (Perfect Filtering) گفته می‌شود، زیرا اعتبارسنجی دقیقا بر مبنای آدرس ۳۲ بیتی کامل Class D در هدر IPv4 انجام می‌گیرد. در این سناریو، لایه IP بسته را تایید کرده و به لایه UDP می‌فرستد؛ سپس لایه UDP نیز دیتاگرام را به سوکت متصل به پورت 123 تحویل می‌دهد.

Multicasting در شبکه‌های گسترده (WAN)

همان‌طور که در بخش قبل دیدیم، پیاده‌سازی مالتی‌کست در یک شبکه محلی (LAN) بسیار ساده است: یک هاست بسته مالتی‌کست را ارسال می‌کند و تمام هاست‌های علاقه‌مند آن را تحویل می‌گیرند. برتری چشمگیر مالتی‌کست نسبت به برودکست در این است که هاست‌های غیرعلاقه‌مند درگیر پردازش بسته‌های غیرضروری نمی‌شوند و بار محاسباتی آن‌ها به حداقل می‌رسد.

این مزایای مالتی‌کست در مقیاس شبکه‌های گسترده (WAN) نیز نمود پیدا می‌کند. در دیاگرام بالا، یک شبکه WAN شامل ۵ شبکه LAN را مشاهده می‌کنید که هر کدام به یک روتر مالتی‌کست متصل هستند.

فرض کنید روی ۵ هاست مختلف، برنامه‌ای اجرا شده است (مانند برنامه‌ای برای پخش استریم صوتی مالتی‌کست). این ۵ برنامه به یک گروه مالتی‌کست خاص می‌پیوندند و در نتیجه هاست‌های آن‌ها نیز عضو آن گروه می‌شوند. همچنین فرض می‌کنیم تمام روترهای مالتی‌کست از طریق پروتکل مسیریابی مالتی‌کست یا MRP (مخفف Multicast Routing Protocol) با روترهای مجاور خود در ارتباط هستند.

در تصویر بالا، فرآیند انتقال و انتشار بسته مالتی‌کست از سمت فرستنده به تمام گیرنده‌ها به وضوح نشان داده شده است.

1. ابتدا فرستنده در شبکه LAN بالا سمت چپ، بسته را به صورت مالتی‌کست ارسال می‌کند. گیرنده H1 به دلیل عضویت در گروه، بسته را دریافت می‌کند. روتر MR1 نیز بسته را تحویل می‌گیرد (چرا که روترهای مالتی‌کست موظف به دریافت تمامی بسته‌های مالتی‌کست هستند).
2. سپس MR1 بسته مالتی‌کست را به MR2 هدایت می‌کند، زیرا پروتکل MRP به MR1 اعلام کرده است که MR2 نیازمند دریافت بسته‌های این گروه مالتی‌کست است.
3. روتر MR2 از آنجا که هاست‌های H2 و H3 عضو گروه هستند، بسته را درون LAN متصل به خود به صورت مالتی‌کست پخش می‌کند. افزون بر این، یک کپی از بسته تهیه کرده و آن را به سمت MR3 می‌فرستد. کپی کردن بسته توسط MR2 در این مرحله، یکی از ویژگی‌های منحصربه‌فرد فرآیند Forwarding در مالتی‌کست است؛ در حالی که بسته‌های Unicast هنگام عبور از روترها هرگز تکثیر نمی‌شوند.
4. روتر MR3 بسته مالتی‌کست را به سمت MR4 ارسال می‌کند، اما هیچ نسخه‌ای از آن را به LAN محلی خود نمی‌فرستد؛ چرا که هیچ هاستی در این LAN عضو گروه نشده است.
5. در نهایت، MR4 با توجه به عضویت هاست‌های H4 و H5، بسته را در LAN محلی خود پخش می‌کند. با این حال، به دلیل اطلاعات مسیریابی مبادله‌شده با MR5، می‌داند که هیچ هاستی در LAN متصل به MR5 عضو این گروه نیست؛ بنابراین نسخه‌ای برای MR5 ارسال نخواهد کرد.

اگر بخواهیم بدون استفاده از قابلیت مالتی‌کست در WAN به نتیجه مشابهی برسیم، ناچاریم یکی از دو رویکرد زیر را به کار بگیریم:

روش نخست، Broadcast Flooding نام دارد؛ در این روش فرستنده بسته را Broadcast می‌کند و سپس تک‌تک روترها بسته را روی تمام اینترفیس‌ها (به‌جز اینترفیس ورودی) مجددا Broadcast می‌کنند. نتیجه کار، تحمیل حجم عظیمی از پردازش و ترافیک به هاست‌ها و روترهایی است که اساساً نیازی به این داده‌ها ندارند.

روش دوم، ارسال یک نسخه اختصاصی برای هر گیرنده است. در این سناریو فرستنده باید آدرس IP تک‌تک گیرنده‌ها را بداند و برای هرکدام یک کپی مجزا بفرستد. در مثال بالا با ۵ گیرنده، ۵ بسته در LAN فرستنده، ۴ بسته در مسیر MR1 به MR2 و ۲ بسته در مسیر MR2 از طریق MR3 به MR4 تولید می‌شود. حالا تصور کنید شمار گیرنده‌ها به یک میلیون نفر برسد!

رویکرد مالتی‌کست مبتنی بر مبدا خاص (Source-Specific Multicast)

پیاده‌سازی و استقرار مالتی‌کست در شبکه‌های WAN به دلایل متعددی کاری دشوار و چالش‌برانگیز است. بزرگ‌ترین معضل این است که پروتکل MRP باید بتواند داده‌ها را از فرستنده‌های مستقر در هر کجای شبکه به گیرندگان مستقر در هر نقطه دیگر برساند. چالش دیگر، تخصیص آدرس‌های مالتی‌کست است؛ فضای آدرس‌دهی IPv4 Multicast بر خلاف آدرس‌های Unicast به اندازه‌ای نیست که بتوان آن را به صورت ایستا به همه اختصاص داد. برای ارسال داده‌های مالتی‌کست در مقیاس وسیع بدون تداخل با سایر فرستنده‌ها به آدرس‌های یکتا نیاز است، اما هنوز مکانیزم جهان‌شمولی برای تخصیص آدرس‌های مالتی‌کست وجود ندارد.

مدل SSM (مخفف Source-Specific Multicast) این چالش‌ها را به خوبی حل می‌کند. این روش با ترکیب آدرس گروه با آدرس مبدا (Source Address) سیستم فرستنده، مسائل را به شکل زیر مدیریت می‌کند:

• هنگام عضویت در گروه، گیرنده‌ها آدرس مبدا فرستنده را به روتر ارائه می‌دهند. از آنجا که اکنون شبکه موقعیت دقیق فرستنده را می‌داند، معضل Rendezvous در شبکه برطرف می‌شود. در عین حال، مزیت مقیاس‌پذیری (بی‌نیازی فرستنده از شناسایی تک‌تک گیرندگان) کاملا حفظ شده و در نتیجه پروتکل‌های مسیریابی مالتی‌کست بسیار ساده‌تر می‌شوند.
• در SSM، شناسه به جای یک آدرس ساده گروه مالتی‌کست، به صورت ترکیبی از مبدا Unicast و مقصد Multicast (که اصطلاحاً به آن کانال یا Channel می‌گویند) تعریف می‌شود. از آنجا که بخش مبدا تضمین‌کننده یکتایی است، زوج (Source, Destination) همواره یکتا خواهد بود؛ بنابراین فرستنده می‌تواند بدون نگرانی از تداخل، هر آدرس مالتی‌کستی را انتخاب کند. در نهایت، یک نشست یا Session در SSM با ترکیب مبدا، مقصد و پورت مشخص می‌شود.

تنظیمات سوکت برای Multicast (سوکت آپشن‌ها)

گزینه‌های مربوط به ارسال دیتاگرام‌های Multicast

در APIهای سنتی مالتی‌کست، ۵ گزینه سوکت (Socket Option) جدید مورد استفاده قرار می‌گیرد (یادداشت مترجم: شامل ۳ گزینه عمومی در IPv4/IPv6 به همراه ۲ گزینه برای پیوستن و ترک گروه که در ادامه شرح داده می‌شوند). علاوه بر این، در معماری SSM برای پشتیبانی از فیلترینگ مبدا، ۴ گزینه دیگر نیز اضافه شده است. جدول/تصویر بالا ۳ گزینه سوکتِ مستقل از عضویت (جدا از پیوستن یا ترک گروه) و همچنین نوع داده پارامترها را در فراخوانی توابع getsockopt یا setsockopt نشان می‌دهد.

گزینه‌های IP_MULTICAST_IF و IPV6_MULTICAST_IF

این گزینه‌ها اینترفیس مورداستفاده برای ارسال دیتاگرام‌های مالتی‌کست را تعیین می‌کنند. در IPv4 این کار با استفاده از ساختار in_addr و در IPv6 با Interface Index مشخص می‌شود. اگر اینترفیس به صورت صریح تعیین نشود (مثلاً با تنظیم INADDR_ANY یا مقدار 0 برای ایندکس در APIهای مستقل از پروتکل)، مقدار قبلی این گزینه پاک شده و سیستم‌عامل به صورت خودکار برای ارسال هر دیتاگرام، مناسب‌ترین اینترفیس را برمی‌گزیند.

به عنوان یک نکته کلیدی، همواره باید میان اینترفیسی که برای دریافت دیتاگرام‌های مالتی‌کست لوکال تعیین شده با اینترفیسی که برای ارسال (خروجی) دیتاگرام‌ها استفاده می‌شود، تفاوت قائل شد.

گزینه‌های IP_MULTICAST_TTL و IPV6_MULTICAST_HOPS

این دو گزینه به ترتیب مقدار TTL (Time to Live) در IPv4 یا Hop Limit در IPv6 را برای دیتاگرام‌های خروجی مالتی‌کست تعیین می‌کنند. چنانچه مقداری برای آن‌ها مشخص نشود، مقدار پیش‌فرض برابر با ۱ در نظر گرفته خواهد شد که به این معنی است بسته فقط در محدوده همان Subnet محلی منتشر می‌شود.

گزینه‌های IP_MULTICAST_LOOP و IPV6_MULTICAST_LOOP

این گزینه‌ها برای فعال یا غیرفعال کردن قابلیت Local Loopback در دیتاگرام‌های مالتی‌کست کاربرد دارند. Loopback به صورت پیش‌فرض فعال است؛ بنابراین اگر هاست خودش عضو گروه مالتی‌کست در اینترفیس ارسال‌کننده باشد، یک کپی از هر دیتای ارسالی به خود هاست بازگردانده شده (Loopback) و مثل یک بسته دریافتی پردازش می‌شود.

این رفتار در Broadcasting نیز برقرار است؛ در برودکست، بسته‌ای که هاست ارسال می‌کند توسط خودش نیز دریافت و پردازش می‌شود، با این تفاوت که در برودکست هیچ راهی برای غیرفعال کردن این ویژگی Loopback وجود ندارد.

گزینه‌های مربوط به دریافت دیتاگرام‌های Multicast

برای دریافت دیتاگرام‌های مالتی‌کست، یک فرآیند (Process) هم باید به گروه مالتی‌کست بپیوندد و هم سوکت UDP را به شماره پورت مقصدی که دیتاگرام‌ها به آن ارسال می‌شوند Bind کند. این دو مرحله کاملاً مستقل از یکدیگرند و انجام هر دوی آن‌ها ضروری است: پیوستن به گروه به لایه‌های IP و Datalink هاست اعلام می‌کند که بسته‌های این گروه مالتی‌کست را دریافت کنند، در حالی که Bind کردن پورت به لایه UDP می‌گوید که دیتاگرام‌های رسیده به آن پورت خاص را به برنامه تحویل دهد.

تصویر فوق گزینه‌های سوکت مرتبط با عضویت در گروه (Membership) را برای IPv4، IPv6 و همچنین APIهای مستقل از نسخه IP نمایش می‌دهد. اشاره‌گری به متغیر از نوع داده مشخص‌شده، به عنوان آرگومان چهارم در توابع getsockopt و setsockopt ارسال می‌شود. هرچند تمامی این ۹ گزینه با setsockopt قابل استفاده هستند، اما ۶ گزینه مربوط به پیوستن و ترک گروه یا مبدا مالتی‌کست را نمی‌توان با getsockopt فراخوانی کرد (یادداشت مترجم: ظاهراً منظور مجموع ۹ گزینه بر مبنای IPv4 است).

اکنون به بررسی دقیق‌تر این ۹ گزینه سوکت می‌پردازیم. توجه داشته باشید که این گزینه‌ها از لحاظ مفهومی در هر دو پروتکل IPv4 و IPv6 یکسان هستند و تنها نام و نوع آرگومان‌های ورودی آن‌ها تفاوت دارد.

گزینه‌های IP_ADD_MEMBERSHIP، IPV6_JOIN_GROUP و MCAST_JOIN_GROUP

این گزینه‌ها برای پیوستن به یک گروه مالتی‌کست از هر مبدئی (Any-Source Multicast Group یا ASM) بر روی یک اینترفیس محلی به کار می‌روند. اینترفیس محلی را می‌توان در IPv4 با یکی از آدرس‌های Unicast، در IPv6 با ایندکس اینترفیس، یا با استفاده از APIهای مستقل از پروتکل تعیین کرد. برای پیوستن یا ترک گروه، از سه ساختار (Structure) زیر استفاده می‌شود:

چنانچه کاربر تمایلی به تعیین یک اینترفیس خاص نداشته باشد، می‌تواند در IPv4 از مقدار INADDR_ANY و در IPv6 از مقدار 0 برای ایندکس استفاده کند.

زمانی که حتی یک پروسس روی یک اینترفیس خاص عضو یک گروه باشد، آن هاست اصطلاحاً به عنوان عضوی از آن گروه مالتی‌کست شناخته می‌شود.

یک سوکت می‌تواند چندین بار عملیات Join را انجام دهد، مشروط بر اینکه هر بار به یک آدرس مالتی‌کست متفاوت بپیوندد یا در صورت یکسان بودن آدرس، اینترفیس متفاوتی را نسبت به دفعات قبل انتخاب کند. این ویژگی در هاست‌های چنداینترفیسی (Multihomed Hosts) بسیار کاربردی است؛ به عنوان نمونه می‌توان با یک سوکت واحد، برای هر اینترفیس به صورت مجزا به آدرس مالتی‌کست ملحق شد.

آدرس‌های مالتی‌کست در IPv6 حاوی یک فیلد Scope هستند. همان‌طور که پیش‌تر اشاره شد، حتی اگر تنها مقدار Scope در دو آدرس IPv6 متفاوت باشد، آن‌ها دو گروه کاملاً مجزا تلقی می‌شوند. بنابراین، اگر یک سرویس NTP (مخفف Network Time Protocol) بخواهد تمامی بسته‌های NTP را بدون در نظر گرفتن Scope آن‌ها دریافت کند، باید در تمام آدرس‌های زیر عضو شود:

• ff01::101 (Interface-local)
• ff02::101 (Link-local)
• ff05::101 (Site-local)
• ff08::101 (organization-local)
• ff0e::101 (global)

تمامی این آدرس‌ها را می‌توان روی یک سوکت واحد عضو کرد (Join کرد). با تنظیم گزینه سوکت IPV6_PKTINFO (معرفی‌شده در بخش ۲۲.۸)، هنگام فراخوانی recvmsg() می‌توانید اطلاعات آدرس مقصد بسته دریافتی را به دست آورید. (توضیح مترجم: یعنی گیرنده می‌تواند متوجه شود که فرستنده از چه آدرس چندپخشی یا همان Multicast استفاده کرده است).

IP_DROP_MEMBERSHIP, IPV6_LEAVE_GROUP, MCAST_LEAVE_GROUP

این گزینه‌ها برای لغو عضویت یک اینترفیس محلی از گروه Multicast مربوط به همه منابع (Any-source) به کار می‌روند و از همان ساختارهایی استفاده می‌کنند که هنگام پیوستن به گروه استفاده شده بودند. اگر اینترفیس محلی مشخص نشده باشد (در IPv4 با مقدار INADDR_ANY و در IPv6 با ایندکس 0 برای اینترفیس)، سیستم نخستین عضویت منطبق با گروه Multicast را حذف می‌کند.

حتی اگر یک فرآیند پس از پیوستن به گروه صراحتاً از آن خارج نشود، با بسته شدن سوکت (چه به صورت دستی و چه با پایان یافتن فرآیند) این عضویت به طور خودکار لغو خواهد شد. همچنین اگر چندین سوکت روی یک میزبان به یک گروه مشترک بپیوندند، میزبان تا زمانی که آخرین سوکت از گروه خارج نشود همچنان عضو آن گروه باقی می‌ماند.

IP_BLOCK_SOURCE, MCAST_BLOCK_SOURCE

این گزینه از دریافت ترافیک یک منبع خاص جلوگیری می‌کند، در حالی که اینترفیس محلی تعیین‌شده همچنان در یک گروه any-source عضو است. چنانچه تمامی سوکت‌های عضو، یک منبع یکسان را مسدود کنند، سیستم می‌تواند به روترها اعلام کند که این ترافیک نامطلوب است؛ موضوعی که می‌تواند بر مسیریابی Multicast شبکه تأثیر بگذارد (برای مثال، جهت نادیده گرفتن ترافیک ارسال‌شده از سوی فرستندگان مخرب کاربرد دارد). برای تعیین اینترفیس محلی جهت مسدودسازی، در IPv4 می‌توان از آدرس Unicast استفاده کرد و در API مستقل از پروتکل نیز می‌توان ایندکس اینترفیس را مشخص نمود. برای مسدودسازی یا رفع مسدودی منبع از دو ساختار استفاده می‌شود.

اگر اینترفیس به صورت صریح مشخص نشود (تنظیم با INADDR_ANY یا ایندکس 0 در API مستقل از پروتکل)، اینترفیسی انتخاب می‌شود که سوکت ابتدا از طریق آن به گروه پیوسته بود. از آنجا که درخواست مسدودسازی منبع در واقع ویرایش عضویت گروه است، گروه مورد نظر باید پیش‌تر از طریق گزینه‌های IP_ADD_MEMBERSHIP، IPV6_JOIN_GROUP یا MCAST_JOIN_GROUP روی اینترفیس تعیین‌شده عضو شده باشد.

IP_UNBLOCK_SOURCE, MCAST_UNBLOCK_SOURCE

این گزینه‌ها مسدودسازی قبلی را لغو می‌کنند. آرگومان‌های این درخواست باید دقیقاً با آرگومان‌هایی که پیش‌تر در درخواست‌های IP_BLOCK_SOURCE یا MCAST_BLOCK_SOURCE روی این سوکت استفاده شده بودند، یکسان باشند.

چنانچه اینترفیس به صراحت مشخص نشود (تنظیم با INADDR_ANY یا ایندکس 0 در API مستقل از پروتکل)، نخستین منبع مسدودشده‌ای (blocked source) که سیستم پیدا کند، از حالت مسدود خارج خواهد شد.

IP_ADD_SOURCE_MEMBERSHIP, MCAST_JOIN_SOURCE_GROUP

این گزینه‌ها برای عضویت در یک گروه Multicast وابسته به منبع خاص (source-specific group) روی اینترفیس محلی مشخص‌شده به کار می‌روند و از همان ساختارهای بخش مسدودسازی و رفع مسدودی استفاده می‌کنند. از آنجا که در این روش فقط منابع دلخواه برای دریافت تعیین و عضو می‌شوند، نباید پیش از این از طریق اینترفیس‌های any-source (مانند IP_ADD_MEMBERSHIP، IPV6_JOIN_GROUP یا MCAST_JOIN_GROUP) عضویتی ایجاد شده باشد.

اگر اینترفیس صراحتاً تعیین نشود (تنظیم با INADDR_ANY یا ایندکس 0 در API مستقل از پروتکل)، کرنل سیستم‌عامل به صورت خودکار آن را انتخاب می‌کند.

IP_DROP_SOURCE_MEMBERSHIP, MCAST_LEAVE_SOURCE_GROUP

این گزینه‌ها برای لغو عضویت از گروه Multicast وابسته به منبع خاص (source-specific group) روی اینترفیس محلی مشخص‌شده استفاده می‌شوند و ساختار آن‌ها نیز دقیقاً مشابه ساختار مورد استفاده در زمان عضویت است.

در صورتی که اینترفیس به طور صریح مشخص نشده باشد (تنظیم با INADDR_ANY یا ایندکس 0 در API مستقل از پروتکل)، سیستم اولین عضویت منطبق با Multicast وابسته به منبع را حذف می‌کند.

اگر فرآیندی پس از عضویت در یک Multicast وابسته به منبع خاص صراحتاً از گروه خارج نشود، با بسته شدن سوکت (چه با بستن صریح و چه با خاتمه فرآیند)، عضویت به صورت خودکار لغو می‌شود. همچنین چند فرآیند مختلف روی یک میزبان می‌توانند در یک گروه Multicast وابسته به منبع عضو شوند که در این حالت میزبان تا زمان خروج آخرین فرآیند، عضویت خود را در آن گروه حفظ خواهد کرد.

تابع mcast_join و توابع مرتبط

گزینه‌های سوکت Multicast در IPv4 و IPv6 بسیار شبیه به یکدیگر هستند، اما تفاوت‌های آن‌ها نیز کم نیست. به همین دلیل کدهایی که قصد دارند به صورت مستقل از پروتکل از Multicast استفاده کنند، با دستورات شرطی `#ifdef` متعددی روبه‌رو و پیچیده می‌شوند. پیاده‌سازی و استفاده از توابعی مستقل از پروتکل که در هر دو نسخه IPv4 و IPv6 قابل استفاده باشند، این مشکل را برطرف می‌کند.

تابع mcast_join

تابع mcast_join با استفاده از آدرس IP موجود در ساختار آدرس سوکت grp، به یک گروه Multicast از نوع any-source می‌پیوندد. اینترفیس را می‌توان با نام یا ایندکس آن (ifindex، مقداری غیر از صفر) تعیین کرد؛ اگر هیچ‌کدام مشخص نشوند، کرنل اینترفیس مناسب را برای پیوستن به گروه انتخاب خواهد کرد.

تابع mcast_leave

این تابع عضویت در گروه Multicast مشخص‌شده در grp را لغو می‌کند. در اینجا امکان تعیین اینترفیس وجود ندارد و اولین عضویت منطبق حذف خواهد شد؛ بنابراین اگر قصد مدیریت عضویت روی یک اینترفیس خاص را دارید، باید مستقیماً از API دستور setsockopt استفاده کنید.

تابع mcast_block_source

این تابع بسته‌های Multicast دریافتی از یک منبع خاص را مسدود می‌کند؛ به طوری که آدرس منبع مورد نظر در src و آدرس گروه در grp قرار می‌گیرد. پیش از فراخوانی این تابع، سوکت باید ابتدا با تابع mcast_join به گروه پیوسته باشد.

این تابع در سوکت داده‌شده، دریافت ترافیک از منبع و گروهی را که آدرس‌های IP آن‌ها در ساختارهای آدرس سوکت با اشاره‌گرهای src و grp قرار دارد مسدود می‌سازد. طول این ساختارها نیز به ترتیب با srclen و grplen تعیین می‌شود. لازم است پیش‌تر روی این سوکت تابع mcast_join برای گروه مربوطه فراخوانی شده باشد.

تابع mcast_unblock_source

این تابع مسدودسازی ترافیک ارسالی از منبع به گروه را لغو می‌کند. مقادیر آرگومان‌های src، srclen، grp و grplen باید دقیقاً مشابه مقادیری باشد که پیش‌تر در فراخوانی mcast_block_source استفاده شده بود.

تابع mcast_join_source_group

این تابع برای پیوستن به یک گروه Multicast وابسته به منبع خاص (Source-specific multicast) استفاده می‌شود. منبع دریافتی با src و گروه با grp مشخص می‌شود. اینترفیس هدف را نیز می‌توان با نام یا ایندکس اینترفیس تعیین کرد؛ در صورت عدم تعیین، انتخاب آن بر عهده کرنل خواهد بود.

تابع mcast_leave_source_group

این تابع عضویت در گروه Multicast وابسته به منبع خاص (Source-specific multicast) را لغو می‌کند. منبع با src و گروه با grp مشخص می‌شود و همانند تابع mcast_leave، امکان مشخص کردن اینترفیس وجود ندارد و اولین عضویت منطبق لغو می‌گردد.

تابع mcast_set_if

اینترفیس پیش‌فرض را برای ارسال بسته‌های Multicast تنظیم می‌کند. اگر مقدار ifindex بزرگ‌تر از 0 باشد، اینترفیس با ایندکس مشخص می‌شود و اگر ifindex کوچک‌تر یا مساوی 0 بوده ولی مقدار ifname مخالف null باشد، اینترفیس بر اساس نام آن تعیین می‌گردد.

تابع mcast_set_loop

گزینه Loopback را روی مقدار 0 یا 1 تنظیم می‌کند.

تابع mcast_set_ttl

مقدار TTL در IPv4 یا محدودیت گام (hop limit) در IPv6 را تعیین می‌کند.

توابع mcast_get_if، mcast_get_loop و mcast_get_ttl

این توابع مقادیر متناظر با هر یک از تنظیمات فوق را برمی‌گردانند.

مثال: تابع mcast_join

کد زیر بخشی از پیاده‌سازی تابع mcast_join را نشان می‌دهد. همان‌طور که می‌بینید، پیاده‌سازی یک API مستقل از پروتکل به شکلی ساده و روان امکان‌پذیر است.

در ادامه، بخش بعدی تابع mcast_join آورده شده که سوکت‌های IPv4 را مدیریت می‌کند.

بخش پایانی زیر نیز به مدیریت IPv6 اختصاص دارد.

مثال: تابع mcast_set_loop

کد زیر پیاده‌سازی تابع mcast_set_loop را نشان می‌دهد. از آنجا که آرگومان ورودی به جای ساختار آدرس، یک توصیف‌کننده سوکت است، ابتدا با فراخوانی تابع sockfd_to_family خانواده آدرس سوکت به دست می‌آید و سپس گزینه سوکت مناسب بر اساس آن تنظیم می‌شود.

ارسال و دریافت چندپخشی (Multicast)

بیایید یک برنامه کاربردی و ساده برای ارسال و دریافت دیتاگرام‌های Multicast بسازیم. این برنامه از دو بخش تشکیل شده است: بخش نخست هر ۵ ثانیه یک بار یک دیتاگرام Multicast حاوی نام میزبان و شناسه فرآیند (Process ID) فرستنده را ارسال می‌کند. بخش دوم شامل یک حلقه بی‌نهایت است که به همان گروه Multicast می‌پیوندد و تمامی دیتاگرام‌های دریافتی (شامل نام میزبان و شناسه فرآیند فرستنده) را چاپ می‌کند. با اجرای این برنامه روی چندین میزبان در یک شبکه LAN، به راحتی می‌توان بررسی کرد که کدام میزبان دیتاگرام‌ها را از کدام فرستنده دریافت می‌نماید.

کد زیر دو سوکت مجزا برای ارسال و دریافت ایجاد می‌کند. سوکت گیرنده باید به گروه Multicast و پورت مربوطه Bind شود و سپس به گروه Multicast بپیوندد. سوکت فرستنده نیز دیتاگرام‌ها را به همان آدرس Multicast و پورت مورد نظر ارسال خواهد کرد.

اگر بخواهید از یک سوکت واحد برای ارسال و دریافت استفاده کنید، آدرس پروتکل مبدأ که به سوکت Bind شده به عنوان آدرس IP مبدأ در دیتاگرام UDP قرار می‌گیرد؛ اما طبق استاندارد RFC 1122 [Braden 1989]، استفاده از آدرس‌های Multicast یا Broadcast به عنوان آدرس مبدأ یک بسته IP ممنوع است. به همین دلیل، ایجاد دو سوکت مجزا برای ارسال و دریافت الزامی است.

کد زیر هر ۵ ثانیه یک بار یک دیتاگرام Multicast ارسال می‌کند. تابع اصلی مقادیری شامل توصیف‌کننده سوکت، اشاره‌گری به ساختار آدرس سوکت (شامل مقصد Multicast و پورت) و طول این ساختار را به عنوان آرگومان منتقل می‌کند.

در ادامه، کد تابع recv_all مربوط به حلقه بی‌نهایت دریافت آورده شده است.

نمونه اجرا

این برنامه را روی دو سیستم freebsd4 و macosx اجرا می‌کنیم. مشاهده می‌شود که هر سیستم به خوبی بسته‌های ارسالی سیستم دیگر را دریافت کرده و نمایش می‌دهد.

جمع‌بندی

برنامه‌های کاربردی Multicast با پیوستن به یک گروه Multicast کار خود را آغاز می‌کنند. این اقدام به لایه IP اطلاع می‌دهد که عضویت صورت گرفته و لایه IP نیز به نوبه خود به لایه پیوند داده (Data Link) دستور می‌دهد فریم‌های ارسالی به آن آدرس Multicast را دریافت کند. فناوری Multicast از فیلترینگ سخت‌افزاری موجود در کارت‌های شبکه استفاده می‌کند؛ هرچه این فیلتر دقیق‌تر عمل کند، بار بسته‌های ناخواسته کمتر می‌شود و بدین ترتیب بار پردازشی سایر میزبان‌هایی که در برنامه مشارکتی ندارند به حداقل می‌رسد.

پیاده‌سازی Multicasting در شبکه‌های گسترده (WAN) نیازمند روترهایی با قابلیت Multicast و پروتکل‌های مسیریابی مخصوص آن است. تا زمانی که تمامی روترهای اینترنت به این قابلیت مجهز نشوند، تنها بخشی از کاربران امکان استفاده از آن را خواهند داشت. ما مجموعه تمام سیستم‌های با قابلیت Multicast در سراسر اینترنت را «IP multicast infrastructure» می‌نامیم.

منبع

• Unix Netork Programming third edition