Dźwięk i obraz w Internecie (1):
Multicasting

Coraz większą popularność w ostatnim czasie zyskują sobie - aczkolwiek są one jeszcze ciągle usługą o charakterze raczej eksperymentalnym - transmisje wizualne i dźwiękowe w Internecie. Oprogramowanie służące do tych celów dostępne jest już nie tylko na Unixowe stacje robocze, ale nawet na zwykłe PC z systemem MS Windows. Nie tak dawno polska prasa komputerowa okrzyczała sensacją jeden z takich programów (nie pierwszy i nie ostatni...), pozwalający prowadzić rozmowy pseudo-telefoniczne przez Internet. W samej tylko Polsce miały miejsce w ostatnim czasie trzy duże transmisje audiowizualne w sieci (I Konferencja "Internet w Polsce", II tura Walnego Zgromadzenia PSI oraz IV finał Wielkiej Orkiestry Świątecznej Pomocy), na świecie zaś podobne transmisje mają miejsce niemal codziennie. Transmitowane są w ten sposób zarówno wydarzenia okazjonalne, jednorazowe, takie jak np. koncerty, albo niedawna wizyta papieża w Stanach Zjednoczonych, jak i stanowiące już swego rodzaju rutynę (obrady Kongresu USA, loty promów kosmicznych, a przede wszystkim wiele seminariów i konferencji związanych z komputerami i Internetem, np. USENIX czy IETF - od tych ostatnich zaczęła się zresztą cała historia transmisji dźwiękowych przez Internet). Istnieją już nawet radiostacje "nadające" swój program w Internecie (w Polsce przez pewien okres eksperymentalnie retransmitowany był program akademickiego radia RAK z Krakowa).

Obecnie dostępnych i stosowanych jest wiele różnych programów do przesyłania dźwięku w sieci (trochę mniej jest aplikacji pozwalających przesyłać obraz). Dokładniejsza prezentacja poszczególnych rozwiązań znajdzie się w drugiej części tego artykułu, niniejszy natomiast tekst ma na celu przedstawienie podstaw technicznych, umożliwiających w ogóle transmisje audiowizualne w Internecie na szeroką skalę.

Transmisje tego typu niosą bowiem ze sobą znaczne obciążenie sieci. Pasmo zajmowane przez nieskompresowany cyfrowy sygnał foniczny określa się standardowo na 64 Kbps (taki standard przyjmowany jest np. w telefonii). Odpowiednia kompresja realizowana przez współczesne oprogramowanie przesyłu dźwięku potrafi zmniejszyć ilość transmitowanych danych nawet do 9 Kbps (format LPC), aczkolwiek taka kompresja może być niemożliwa do zrealizowania w czasie rzeczywistym na słabszych komputerach; bardziej "przystępne" czasowo algorytmy kompresji generują obciążenie rzędu 17 Kbps (format GSM) lub jeszcze większe dla innych formatów. Transmisje wizyjne o sensownej jakości wymagają przepustowości rzędu co najmniej 100 Kbps. Prawdziwym problemem jest jednakże nie przepustowość łącza do końcowego użytkownika, lecz znajdujących się "po drodze" łączy międzymiastowych i międzynarodowych. Jeżeli wiele osób równocześnie zechce odbierać jakąś transmisję dźwiękową, a zwłaszcza wizyjną, łącze o dowolnie dużej przepustowości może ulec "zapchaniu". Pakiety niosące transmisję muszą bowiem zostać wysłane do każdego odbiorcy z osobna - wynika to z natury protokołu TCP/IP! Transmisja będzie zatem przesyłana w tylu kopiach, ilu jest odbiorców. Jeżeli np. jeden użytkownik w Polsce zechce oglądać nadawany z USA audiowizualny przekaz z koncertu grupy Rolling Stones, generuje to na głównym polskim łączu do świata (ma ono przepustowość 2 Mbps) ciągłe obciążenie rzędu - powiedzmy - 200 Kbps. Obciązenie takie jest do przyjęcia, ale jeżeli tę samą transmisję zechce oglądać równocześnie 10 osób, łącze zacznie "pękać w szwach". To jednakże jeszcze nic w porównaniu z przepustowością łączy, którymi musiałby być dołączony do sieci komputer nadający tę transmisję: aby móc umożliwić jej odbiór setkom, czy tysiącom odbiorców na całym świecie, przepustowość ta musiałaby znacznie przekraczać istniejące możliwości techniczne!

Jednoznacznym wnioskiem jest zatem, że transmisji tego typu nie da się realizować w oparciu o "zwykły" protokół TCP/IP, w którym każdy pakiet przesyłany jest wyłącznie do jednego konkretnego odbiorcy (w zastosowaniach audiowizualnych określane jest to jako unicasting). "Zwykłe" TCP/IP może być wystarczające jedynie do wspomnianych zastosowań typu "telefon przez Internet", gdzie rozmawiają ze sobą tylko dwie osoby. Efektywną realizację wieloosobowych telekonferencji, czy transmisji przeznaczonych dla wielu odbiorców, uzyskuje się natomiast obecnie na ogół dzięki rozszerzeniu standardowego protokołu TCP/IP o tak zwany multicasting.

Multicasting.

W standardowym protokole TCP/IP można wyróżnić pod względem sposobu adresowania dwa rodzaje pakietów. "Zwykłe" pakiety (określane też jako unicast) adresowane są do jednego konkretnego odbiorcy - na konkretny adres IP danego komputera. Drugi rodzaj stanowią pakiety typu broadcast, wykorzystywane na ogół przez protokoły sieciowe do wewnętrznych celów "administracyjnych" (np. ustalenie przyporządkowania adresów IP do adresów fizycznych), odbierane przez wszystkie komputery w lokalnej podsieci. Adres, na jaki wysyła się takie pakiety (broadcast address) tworzony jest poprzez wypełnienie części adresu IP odpowiadającej numerowi komputera w sieci (zgodnie z ustaloną maską podsieci) samymi bitami "1", jak to zilustrowano na poniższym schemacie:

[Rysunek - kliknij tutaj]

Pakiety typu broadcast docierają wprawdzie do wszystkich komputerów w sieci lokalnej bez konieczności wysyłania ich w wielu kopiach, jednakże z oczywistych względów nie mogą być "wypuszczane" przez routery poza sieć lokalną, gdyż szybko doprowadziłyby do "zapchania" całego Internetu - abstrahując już od tego, że niesiona przez nie informacja w większości nie ma poza siecią lokalną żadnego znaczenia.

Multicasting, opisany przez dokument RFC 1112, wprowadza trzeci rodzaj adresowania, które pozwala przesyłać pakiety do wielu (ale nie wszystkich, lecz tylko wybranej grupy) komputerów naraz, i to nie tylko w obrębie sieci lokalnej, ale również - przy zastosowaniu pewnych dodatkowych rozwiązań technicznych - w całym Internecie.

W pakietach typu multicast korzysta się z adresów IP należących do tzw. klasy adresowej D, czyli zawierających na pierwszych 4 bitach adresu kombinację "1110", co daje zakres adresów IP od 224.0.0.0 do 239.255.255.255 (w "zwykłym" TCP/IP używane są adresy z klas A - zaczynające się bitem "0", B - kombinacją "10" i C - "110"). W myśl specyfikacji TCP/IP, wysyłanie pakietów na takie adresy nie powinno wywoływać żadnej reakcji ze strony komputerów nie obsługujących multicastingu.

Adres multicastingowy określa grupę komputerów, do których wysyłany jest pakiet; sposób używania tego adresu jest jednak niejako odwrotny do zwykłych adresów IP. Zwykły adres IP jest jednoznacznie przypisany do określonego komputera, do którego chcemy wysłać pakiet. Adres multicastingowy związany jest raczej z daną sesją - nadawanym ciągiem pakietów - niż z jakimkolwiek konkretnym komputerem; używając analogii radiowej możnaby porównać go do "częstotliwości", na której dana transmisja jest nadawana. "Częstotliwość" tę (czyli adres) wybiera nadawca - decydując np. "będę nadawać do grupy 231.154.162.11", a odbiorca chcąc odbierać daną transmisję musi "dostroić się" do niej, czyli przyłączyć się do grupy identyfikowanej przez dany adres. Komputery mające zaimplementowaną obsługę multicastingu mogą - wykorzystując nowe funkcje dodane do biblioteki sockets - w dowolnym momencie dołączać się i odłączać od dowolnych adresów grupowych; całkowicie dozwolone jest również, aby dany komputer należał do kilku grup (tzn. mógł odbierać kilka transmisji) jednocześnie. Jeżeli więc przykładowo w sieci nadawane są równocześnie dwie transmisje, pierwsza na "częstotliwości" np. 230.136.22.1, a druga na 230.136.22.2 (tzn. na takie adresy komputery nadające wysyłają pakiety), to komputer, który wykona operację przyłączenia się do grupy o adresie 230.136.22.1, będzie odbierał pierwszą z tych transmisji, komputer, który przyłączy się do grupy 230.136.22.2 - drugą, zaś komputer, w którym wykonane zostaną obie te operacje po kolei, będzie odbierał obie transmisje równocześnie. Można rzecz jasna przyłączyć się także do grupy, do której aktualnie nie jest nadawana żadna transmisja (np. 230.136.22.3) - wtedy nie odbiera się oczywiście żadnych pakietów (ale można samemu zacząć nadawać...)

Z powyższego opisu wynika, że zaimplementowanie w danym systemie operacyjnym obsługi multicastingu wymaga pewnych zmian w jądrze TCP/IP (zmiany te opisane są we wspomnianym dokumencie RFC 1112) w stosunku do systemu obsługującego jedynie "zwykły" unicasting. Z multicastingu korzysta się obecnie na ogół w systemach Unixowych. Niektóre z nich mają niezbędne rozszerzenia zawarte już od razu w wersji dystrybucyjnej (z popularniejszych w Polsce są to np. IRIX dla komputerów Silicon Graphics, Solaris 2.x dla komputerów Sun, a także najnowsze wersje popularnych darmowych Unixów dla PC - FreeBSD i Linux), do większości innych dostępne są (przez anonymous ftp) odpowiednie programy pozwalające doinstalować obsługę multicastingu w jądrze. Z nie-Unixowego oprogramowania na komputery PC, multicasting realizują jądra TCP/IP firmy FTP Software: PC/TCP (dla systemu DOS) oraz OnNet (dla Windows) - niestety komercyjne, natomiast bez dodatkowych kosztów jest on już "firmowo" zaimplementowany w 32-bitowym Winsock'u Windows NT i Windows 95. Wreszcie ostatnią platformą, na której realizować można multicasting, jest Macintosh - zapewnia to zawarty w Systemie 7.5.2 moduł sieciowy OpenTransport.

Routery multicastingowe.

Na kolejny problem natykamy się jednakże, gdy transmisje multicastingowe zechcemy przesyłać poza sieć lokalną. Tylko nieliczne spośród routerów łączących poszczególne podsieci składające się na Internet potrafią routować pakiety z adresami typu multicast (możliwość taką mają m.in. routery Cisco począwszy od wersji 10.1 firmware'u, jednak jej implementacja w tej wersji zawiera błędy; w literaturze [2] znaleźć można informację o poprawnie zaimplementowanym routingu pakietów multicast w - raczej nieznanych w Polsce - routerach Proteon). Na ogół do routowania takich pakietów wykorzystuje się komputery Unixowe z uruchomionym programem routingu multicastingowego - mrouted. Mrouted funkcjonuje zupełnie niezależnie od zasadniczego routera, przez który połączone są sieci - "zwykły" router nie transmituje bowiem pakietów multicastingowych, a mrouted ignoruje wszelkie "zwykłe" (unicastingowe) pakiety TCP/IP. Funkcjonują one zatem równolegle obok siebie, jak to jest pokazane na rys.2 (aczkolwiek fizycznie nie muszą to być dwa oddzielne urządzenia, bo np. na tej samej maszynie Unixowej może równocześnie pracować standardowe oprogramowanie routera i mrouted).

Obecny stan routingu multicastingowego jest jeszcze bardzo daleki od sytuacji, w której pakiety multicastingowe mogłyby być swobodnie przesyłane w całym Internecie. Aktualnie mamy do czynienia z izolowanymi od siebie "multicastingowymi wyspami", składającymi się z jednej lub kilku sieci lokalnych, zawierających komputery z zaimplementowanym multicastingiem i połączonych ze sobą za pomocą mrouted bądź firmowych routerów "rozumiejących" pakiety multicast. W obrębie takiej "wyspy" możliwe są transmisje multicastingowe, prędzej czy później osiągamy jednak jej granicę - router prowadzący do "zewnętrznej" sieci, w której przesyłane są już tylko "zwykłe" pakiety TCP/IP. W takich sytuacjach program mrouted umożliwia tworzenie tzw. tuneli, pozwalających na przekazywanie pakietów multicastingowych pomiędzy "wyspami" niejako tranzytem, poprzez sieci nie zapewniające wsparcia dla multicastingu. Pakiety multicastingowe są w tym celu przez mrouted "zawijane" w zwykłe pakiety TCP/IP i wysyłane na adres drugiego komputera z mrouted, który je "odpakowuje" i przesyła dalej w sieci znowu jako multicast (rys.3). Oczywiście adresy obu "końców" tunelu muszą być zadane w sposób jawny.

"Wyspy" multicastingowe połączone tunelami utworzonymi przez mrouted tworzą w Internecie globalną, wirtualną sieć pozwalającą na przesyłanie transmisji multicastingowych - tzw. MBONE (Multicast Backbone). Sieć MBONE jest jeszcze bardzo "dziurawa" i obejmuje swoim zasięgiem bardzo niewielki obszar Internetu. W Polsce do MBONE należą cztery sieci lokalne w trzech miastach, połączone tunelami (zob.rys.4): sieć Instytutu Matematyki i Informatyki Uniwersytetu im. Mikołaja Kopernika w Toruniu, skupiona wokół routera mbone.mat.uni.torun.pl, część sieci lokalnej Cyfronetu w Krakowie, z routerem mg.cyf-kr.edu.pl, Uczelniane Centrum Informatyki Akademii Górniczo-Hutniczej, również w Krakowie (router galaxy.uci.agh.edu.pl), oraz część sieci lokalnej NASK-u w Warszawie, z obsługującym tunel do Sztokholmu routerem legolas.nask.waw.pl. W trakcie uruchamiania jest router multicastingowy na serwerze Internetu dla Szkół w Warszawie - idsserv.waw.ids.edu.pl.

Układ tuneli łączących poszczególne "wyspy" w MBONE wypracowywany jest w sposób nieco podobny, jak struktura feedów Usenetowych, na drodze wzajemnych uzgodnień między administratorami poszczególnych sieci dołączających się do MBONE - chodzi o utworzenie struktury jak najbardziej optymalnej, obciążającej łącza w możliwie najmniejszym stopniu. Szacuje się, iż pasmo przepustowe całej MBONE wynosi obecnie około 300 do 500 Kbps, a więc pozwala na równoczesne przesyłanie nawet kilku transmisji wideo lub kilkunastu audio (zwłaszcza przy dużym stopniu kompresji). W rzeczywistości w sieci może być przesyłanych więcej transmisji równocześnie, jako że routery multicastingowe przesyłają pakiety tylko do tych podsieci, w których rzeczywiście "ktoś słucha" danej transmisji, tzn. w których znajduje się chociaż jeden komputer należący do danej grupy. Każdy komputer dołączając się bądź odłączając od grupy wysyła specjalny pakiet, informujący o tym fakcie wszystkie komputery w sieci lokalnej - a przede wszystkim routery. Niezależnie od tego, routery w ustalonych odstępach czasu "odpytują" wszystkie komputery w sieci lokalnej, uzyskując informację o ich aktualnej przynależności do grup (wszystkie te komunikaty wysyłane są rzecz jasna jako multicast - wykorzystywany jest w tym celu specjalny "administracyjny" adres 224.0.0.1). Dzięki tym informacjom router multicastingowy, zupełnie analogicznie jak "normalny" router, może przepuszczać do danej podsieci tylko te pakiety, które rzeczywiście mają odbiorców w tej podsieci.

Istnieje również uzupełniający mechanizm, pozwalający niejako "odgórnie" ograniczać zasięg transmisji multicastingowej. Specyfikacja przedstawiona w RFC 1112 zawiera wymaganie, aby w komputerach obsługujących multicasting istniała możliwość określania przez aplikację wartości tzw. parametru TTL (time-to-live, czas życia) wysyłanych pakietów multicastingowych. Każdy router multicastingowy zmniejsza wartość tego parametru o 1, i gdy osiągnie ona zero, pakiet nie jest przesyłany dalej. Dodatkowo, aby przekroczyć pewne "punkty krytyczne" w MBONE, pakiet musi mieć dostatecznie wysoką wartość TTL. Zgodnie z przyjętą konwencją, pakiety o TTL mniejszym od 32 są ograniczone do tego samego "miejsca" (site), TTL < 64 - do tego samego "regionu", a TTL < 128 - do tego samego kontynentu. Pojęcia "miejsca" oraz "regionu" nie są dokładnie określone i ich interpretacja zależy od lokalnej struktury sieci (w Polsce "miejsce" obejmuje sieć w obrębie jednego miasta). Stosowane są również progi o pośrednich wartościach - przykładowo w Polsce TTL < 40 ogranicza transmisję do obszaru kraju.

Protokoły transportu.

Implementacja multicastingu w jądrze systemu operacyjnego czy też routing pakietów multicastingowych to zagadnienia mieszczące się w obrębie warstwy sieciowej IP - ich zrealizowanie pozwala jedynie na wysyłanie pojedynczych datagramów do grup komputerów. Aby rzeczywiście zrealizować za pomocą multicastingu użyteczną transmisję, potrzebny jest protokół transportowy wyższej warstwy, będący odpowiednikiem stosowanych w unicastingu TCP bądź UDP. Multicasting wykorzystywany jest w pierwszym rzędzie na potrzeby "żywych" transmisji audio i wideo, gdzie potwierdzanie dotarcia pakietu do adresata i ponawianie transmisji w przypadku przekłamań jest niepotrzebne, a nawet niewskazane - stąd też podstawowym protokołem używanym w multicastingu jest RTP (Real-time Transport Protocol), stanowiący odpowiednik unicastingowego UDP. RTP zapewnia zachowanie właściwej kolejności odbieranych pakietów, nie gwarantuje jednak - analogicznie do UDP - dotarcia pakietów w nienaruszonej postaci (ani dotarcia w ogóle...) do adresata. Z protokołu tego korzystają m.in. powszechnie używane obecnie aplikacje multicastingowe audio/wideo, takie jak vat i nv, które będą omawiane w drugiej części tego tekstu. Opracowano jednak także i multicastingowy odpowiednik TCP - MTP (Multicast Transport Protocol), gwarantujący dostarczenie danych w nienaruszonej postaci. Protokół ten może być zastosowany np. do rozsyłania wiadomości Usenetu, w miejsce stosowanego dotychczas przekazywania tzw. feedów między serwerami metodą "jeden do jednego". Na tego typu zastosowania multicastingu przyjdzie jednakże zapewne zaczekać do czasu, aż większość sieci i komputerów w Internecie będzie mogła przekazywać pakiety multicastingowe.

Literatura:
1. RFC 1112: Host Extensions for IP Multicasting, ftp://ftp.cyf-kr.edu.pl/pub/mirror/rfc/rfc1112.txt.
2. Frequently Asked Questions on the Multicast Backbone, ftp://ftp.isi.edu/mbone/faq.txt.
3. MBONE Information Web, http://www.best.com/~prince/techinfo/mbone.html.
4. IP Multicasting, http://ganges.cs.tcd.ie:80/4ba2/multicast/.

Dziękuję Rafałowi Maszkowskiemu <rzm@torun.pdi.net> za konsultację tekstu oraz informacje o aktualnej topologii sieci MBONE w Polsce.

Jarosław Rafa 1996. Tekst udostępniony na licencji Creative Commons (uznanie autorstwa - użycie niekomercyjne - bez utworów zależnych). Kliknij tutaj, aby dowiedzieć się, co to oznacza i co możesz z tym tekstem zrobić. W razie jakichkolwiek wątpliwości licencyjnych bądź w celu uzyskania zgody na rozpowszechnianie wykraczające poza warunki licencji proszę o kontakt e-mailem: raj@ap.krakow.pl.

Wersja HTML opracowana 3.06.96, ostatnia aktualizacja adresów 29.07.97

Powrót do wykazu artykułów o Internecie Statystyka