Znajdowanie punktów końcowych

Programy serwera nasłuchują punktów dostępowych na żądania klientów. Składnia ciągu punktu końcowego zależy od używanej sekwencji protokołu. Na przykład dla protokołu TCP/IP punktem końcowym jest numer portu, a w przypadku nazwanych potoków prawidłową składnią punktu końcowego jest nazwa potoku.

Istnieją dwa typy punktów końcowych: dobrze znane i dynamiczne. Wybór rodzaju punktu końcowego używanego przez program decyduje o tym, czy punkt końcowy jest określany przez aplikację rozproszoną, czy przez bibliotekę czasu wykonywania.

W tej sekcji omówiono punkty końcowe i przedstawiono informacje na temat ich znajdowania. Jest ona zorganizowana w następujące tematy:

• używanie Well-Known punktów końcowych
• Przy Użyciu Dynamicznych Punktów Końcowych
• eksportowanie punktów końcowych Well-Known do bazy danych mapy punktu końcowego

Aplikacja kliencka może używać mapy punktu końcowego w celu określenia, czy program serwera jest aktualnie uruchomiony. Klient może wywołać RpcMgmtInqIfIds, RpcMgmtEpEltInqBegini RpcMgmtEpEltInqDone, aby sprawdzić, czy serwer zarejestrował określony interfejs, który wymaga w mapie punktu końcowego.

Korzystanie z dobrze znanych punktów końcowych

Dobrze znane punkty końcowe są wstępnie przypisanymi punktami końcowymi, których program serwera używa za każdym razem, gdy jest uruchamiany. Ponieważ serwer zawsze nasłuchuje tego konkretnego punktu końcowego, klient zawsze próbuje nawiązać z nim połączenie. Dobrze znane punkty końcowe są zwykle przypisywane przez urząd odpowiedzialny za protokół transportowy. Ponieważ komputery hosta serwera mają ograniczoną liczbę dostępnych punktów końcowych, deweloperzy aplikacji zdecydowanie odradzają korzystanie z dobrze znanych punktów końcowych. Kolejną zaletą dynamicznych punktów końcowych jest uproszczenie długoterminowego zarządzania i konserwacji systemu.

Aplikacja rozproszona może określić dobrze znany punkt końcowy w ciągu i przekazać ten ciąg jako parametr do funkcji RpcServerUseProtseqEp. Alternatywnie, ciąg punktu końcowego może pojawić się w nagłówku interfejsu pliku IDL w ramach atrybutu interfejsu [punktu końcowego].

Do zaimplementowania dobrze znanego punktu końcowego można użyć dwóch metod:

• Określ wszystkie informacje w wiązaniu tekstowym
• Umieść dobrze znany punkt końcowy w bazie danych usługi nazw.

Podczas opracowywania można napisać wszystkie informacje potrzebne do ustanowienia powiązania w aplikacji rozproszonej. Klient może określić dobrze znany punkt końcowy bezpośrednio w ciągu, wywołać RpcStringBindingCompose, aby utworzyć ciąg zawierający wszystkie informacje o powiązaniu, a następnie przekazać ten ciąg do funkcji RpcBindingFromStringBinding, aby uzyskać dojście. Klient i serwer mogą być zakodowane w kodzie, aby użyć dobrze znanego punktu końcowego lub zapisanego w taki sposób, aby informacje o punkcie końcowym pochodziły z wiersza polecenia, pliku danych, pliku konfiguracji lub pliku IDL.

Aplikacja kliencka może również wysyłać zapytania do bazy danych usługi nazw pod kątem dobrze znanych informacji o punkcie końcowym.

Używanie dynamicznych punktów końcowych

Liczba punktów końcowych dla określonego serwera i określonej sekwencji protokołów jest zwykle ograniczona. Na przykład w przypadku korzystania z sekwencji protokołu ncacn_ip_tcp wskazującej, że komunikacja sieciowa RPC odbywa się przy użyciu protokołu TCP/IP, dostępna jest tylko ograniczona liczba portów (większość systemów ma tylko otwarty zakres od 1025 do 5000). Biblioteki czasu wykonywania RPC umożliwiają dynamiczne przypisywanie punktów końcowych zgodnie z potrzebami. Ponieważ liczba możliwych identyfikatorów UUID interfejsu jest praktycznie nieograniczona, używanie interfejsu UUID do kierowania wywołania oferuje więcej miejsca na rozszerzenie i większą elastyczność.

Domyślnie funkcje biblioteki wykonawczej RPC wyszukują informacje o punkcie końcowym podczas zapytywania bazy danych usługi nazw. Jeśli punkt końcowy jest dynamiczny, baza danych usługi nazw nie będzie zawierać informacji o punkcie końcowym. Jednak zapytanie da programowi klienckim nazwę serwera. Następnie może przeszukiwać mapę punktu końcowego serwera.

Jeśli klient musi wykonać zdalne wywołanie procedury przy użyciu dynamicznego punktu końcowego, preferowaną metodą jest wykonanie wywołania na częściowo powiązanym uchwycie powiązania. Czas wykonywania RPC rozwiązuje punkt końcowy w sposób niewidoczny. Ta metoda jest lepsza od używania funkcji RpcEpResolveBinding, ponieważ umożliwia zaawansowane mechanizmy buforowania w czasie wykonywania RPC.

Jeśli wymagana jest bardziej szczegółowa kontrola nad wyborem punktu końcowego, klienci mogą przeszukiwać jeden wpis mapy punktu końcowego jednocześnie przez wywołanie funkcji RpcMgmtEpEltInqBegin, RpcMgmtEpEltInqNexti funkcji RpcMgmtEpEltInqDone.

Eksportowanie dobrze znanych punktów końcowych do bazy danych mapy punktu końcowego

Istnieje możliwość połączenia dwóch podejść do znajdowania punktów końcowych, zwłaszcza gdy system rozproszony przechodzi z dobrze znanego modelu punktu końcowego do dynamicznego modelu punktu końcowego. W takich przejściach wersja pośrednia serwera będzie używać dobrze znanego punktu końcowego, ale również zarejestruje dobrze znany punkt końcowy w bazie danych mapy punktów końcowych. Takie podejście umożliwia nawiązanie połączenia zarówno klientom korzystającym z dobrze znanego punktu końcowego, jak i klientom korzystającym z dynamicznego punktu końcowego. Po uaktualnieniu wszystkich serwerów można wdrożyć nową wersję klienta, która używa tylko dynamicznych punktów końcowych. Po uaktualnieniu wszystkich klientów ostateczna wersja serwera może przestać używać dobrze znanych punktów końcowych i zacząć korzystać tylko z dynamicznych punktów końcowych.

Takie podejście umożliwia przejście ścieżki dla aplikacji, które rozpoczęły pracę z dobrze znanym punktem końcowym, ale chce przeprowadzić migrację do dynamicznego punktu końcowego bez konieczności jednoczesnej aktualizacji wszystkich serwerów i klientów.