Portowanie aplikacji Broadcast do IPv6

  • 05/31/2018
  • 2 minuty na przeczytanie
    • s
    • v
    • .

    • m

W tej sekcji opisano najlepsze praktyki dotyczące przenoszenia aplikacji rozgłoszeniowej IPv6 do możliwości multicastu dostępnych w usłudze Windows Sockets.

Porównanie IPv4 do IPv6

Najważniejszą kwestią podczas przygotowywania się do przeniesienia aplikacji rozgłoszeniowej IPv4 do IPv6 jest to: IPv6 nie ma zaimplementowanej koncepcji rozgłaszania. Zamiast tego IPv6 używa multicastu.

Multicast dla IPv6 może emulować tradycyjne możliwości rozgłoszeniowe występujące w IPv4. Ustawienie opcji gniazda IPV6_ADD_MEMBERSHIP z adresem IPv6 ustawionym na adres link-local scope all nodes (FF02::1) jest równoważne rozgłaszaniu na adresach rozgłoszeniowych IPv4 przy użyciu opcji gniazda SO_BROADCAST. Ten adres jest czasami nazywany grupą multicastową all-nodes. Dla aplikacji, które po prostu chcą emulacji rozgłaszania dla IPv6, to podejście jest operacyjnie równoważne. Jedną zauważalną różnicą w IPv6 jest jednak to, że multicasty na adresie grupy multicastowej all-nodes nie są domyślnie odbierane (transmisje IPv4 są domyślnie odbierane). Programiści aplikacji muszą użyć opcji gniazda IPV6_ADD_MEMBERSHIP, aby włączyć odbiór multicastów z dowolnego źródła, w tym z adresu grupy multicast all-nodes.

Uwaga

W IPv6 wybór interfejsu jest określony w strukturze argumentów przekazywanych do opcji gniazda multicast lub IOCTL.

Ale dla bogatszych, solidniejszych, bardziej selektywnych i łatwiejszych w zarządzaniu transmisji do wielu hostów, programiści aplikacji powinni rozważyć przejście do modelu multicast.

Przejście do multicast

W przypadku multicastu programiści aplikacji mogą selektywnie wybrać konkretną parę źródło/grupa, umożliwiając selektywny model odbioru. Multicast Listener Discovery (MLD) w IPv6 i wersja 3 protokołu Internet Group Management Protocol (IGMPv3) w IPv4 wspierają programowanie multicastingu. Dodatkowo, multicast umożliwia aplikacjom specjalne blokowanie (lub odblokowywanie) nadawców w obrębie grupy, co dodatkowo chroni aplikacje przed nieuczciwymi nadawcami. Ta możliwość jest dostępna dla IPv4 (wymaga IGMPv3), jak również dla IPv6 (wymaga MLDv2).

Istnieją dwa podstawowe scenariusze dla programistów aplikacji korzystających z multicastingu: te przenoszące z aplikacji rozgłoszeniowych (lub multicastowych) IPv4 do IPv6 oraz te tworzące nowe aplikacje multicastowe IPv6.

W przypadku przenoszenia istniejących aplikacji, istnieją dwie opcje przejścia na IPv6 multicast: użycie opcji gniazda i użycie IOCTLs.

  • Użycie opcji gniazda jest podejściem opartym na zmianach, które umożliwia programistom zmianę właściwości gniazda zgodnie z wymaganiami (takimi jak blokowanie lub odblokowanie nadawcy, dodanie nowego źródła i tak dalej). To podejście jest bardziej intuicyjne i zalecane. Więcej informacji na temat opartego na zmianach podejścia do programowania multicastów można znaleźć w MLD i IGMP Using Windows Sockets.
  • Używanie IOCTLs jest podejściem opartym na stanie końcowym, ponieważ umożliwia programistom zapewnienie w pełni skonfigurowanego stanu gniazda, w tym list włączających i wykluczających, za pomocą jednego wywołania. Aby uzyskać więcej informacji na temat podejścia opartego na stanie końcowym, zobacz Final-State-Based Multicast Programming.

Dla tych, którzy tworzą nowe aplikacje IPv6 multicast, zalecaną praktyką jest użycie opcji gniazda, zamiast używania IOCTLs.

Jest jeszcze jedno podejście do tworzenia aplikacji multicast z IPv6, i to wiąże się z użyciem funkcji WSAJoinLeaf. Chociaż używanie funkcji WSAJoinLeaf nie jest zalecaną praktyką, istnieją sytuacje, które mogą dyktować jej użycie. Na przykład, jedną z wad używania opcji gniazd w Windows Server 2003 i wcześniejszych jest to, że są one specyficzne dla wersji IP. Na tych starszych wersjach Windows, różne opcje gniazd muszą być dla IPv6 i IPv4. W Windows Vista i późniejszych są wspierane nowe opcje gniazd, które mogą być używane zarówno z IPv4 jak i IPv6. Funkcja WSAJoinLeaf jest natomiast niezależna od wersji IP i protokołu, dlatego może być użytecznym podejściem do budowania aplikacji, która musi pracować z wieloma wersjami IP na Windows Server 2003 i wcześniejszych. Użycie funkcji WSAJoinLeaf może być bardziej odpowiednie w pewnych sytuacjach, w których wymagana jest agnostycyzm protokołu i wersji IP.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.