<reliableSession>

Artykuł
06/08/2023

Definiuje ustawienie obsługi komunikatów WS-Reliable. Po dodaniu tego elementu do powiązania niestandardowego wynikowy kanał może obsługiwać dokładnie jednokrotne zapewnienia dostarczania.

<Konfiguracji>
  <System.servicemodel>
    <Powiązania>
      <Custombinding>
        <Wiązania>
          <reliableSession>

Składnia

<reliableSession acknowledgementInterval="TimeSpan"
                 flowControlEnabled="Boolean"
                 inactivityTimeout="TimeSpan"
                 maxPendingChannels="Integer"
                 maxRetryCount="Integer"
                 maxTransferWindowSize="Integer"
                 reliableMessagingVersion="Default/WSReliableMessagingFebruary2005/WSReliableMessaging11"
                 ordered="Boolean" />

Atrybuty i elementy

W poniższych sekcjach opisano atrybuty, elementy podrzędne i elementy nadrzędne.

Atrybuty

Atrybut	Opis
potwierdzenieInterval	Element TimeSpan zawierający maksymalny interwał czasu, który kanał będzie czekać na wysłanie potwierdzenia dla komunikatów odebranych do tego momentu. Wartość domyślna to 00:00:0.2.
flowControlEnabled	Wartość logiczna wskazująca, czy jest aktywowana zaawansowana kontrola przepływu, implementacja funkcji sterowania przepływem specyficzna dla firmy Microsoft na potrzeby obsługi komunikatów WS-Reliable. Wartość domyślna to `true`.
Inactivitytimeout	Element TimeSpan określający maksymalny czas trwania kanału, który pozwoli innej osobie komunikacyjnej nie wysyłać żadnych komunikatów przed błędem kanału. Wartość domyślna to 00:10:00. Działanie w kanale jest definiowane jako odbieranie komunikatów aplikacji lub infrastruktury. Ta właściwość kontroluje maksymalny czas, aby zachować nieaktywną sesję. Jeśli dłuższy czas upływa bez działania, sesja zostanie przerwana przez infrastrukturę i błędy kanału. Uwaga: Nie jest konieczne, aby aplikacja okresowo wysyłała komunikaty w celu zachowania aktywności połączenia.
maxPendingChannels	Liczba całkowita określająca maksymalną liczbę kanałów, które mogą czekać na zaakceptowanie odbiornika. Ta wartość powinna należeć do zakresu od 1 do 16384 włącznie. Wartość domyślna to 4. Kanały oczekują na zaakceptowanie. Po osiągnięciu tego limitu nie są tworzone żadne kanały. Zamiast tego są one umieszczane w trybie oczekiwania, dopóki ta liczba nie spadnie (akceptując oczekujące kanały). Jest to limit na fabrykę. Gdy próg zostanie osiągnięty i aplikacja zdalna spróbuje ustanowić nową niezawodną sesję, żądanie zostanie odrzucone i operacja otwierania, która wywołała te błędy. Ten limit nie dotyczy liczby oczekujących kanałów wychodzących.
maxRetryCount	Liczba całkowita określająca maksymalną liczbę prób ponownego przesłania komunikatu przez niezawodny kanał, dla którego nie odebrano potwierdzenia, wywołując metodę Wyślij w kanale bazowym. Ta wartość powinna być większa niż zero. Wartość domyślna to 8. Ta wartość powinna być liczbą całkowitą większą niż zero. Jeśli potwierdzenie nie zostanie odebrane po ostatniej retransmisji, błędy kanału. Wiadomość jest uważana za przeniesioną, jeśli jej dostarczenie na odbiorcę zostało potwierdzone przez odbiorcę. Jeśli potwierdzenie nie zostało odebrane w określonym czasie dla komunikatu, który został przesłany, infrastruktura automatycznie przesyła wiadomość. Infrastruktura próbuje ponownie wysłać komunikat przez co najwyżej liczbę razy określoną przez tę właściwość. Jeśli potwierdzenie nie zostanie odebrane po ostatniej retransmisji, błędy kanału. Infrastruktura używa algorytmu wycofywania wykładniczego, aby określić, kiedy przeprowadzić ponowne przesłanie, na podstawie obliczonego średniego czasu rundy. Czas początkowo rozpoczyna się o 1 sekundę przed ponownym przesłaniem i podwojeniem opóźnienia przy każdej próbie, co powoduje przekazanie około 8,5 minut między pierwszą próbą transmisji a ostatnią próbą ponownego przesłania. Czas pierwszej próby retransmisji jest dostosowywany zgodnie z obliczonym czasem okrężnej podróży i wynikowym odcinku czasu, który te próby są różne. Dzięki temu czas ponownego transmisji umożliwia dynamiczne dostosowanie się do różnych warunków sieciowych.
maxTransferWindowSize	Liczba całkowita określająca maksymalny rozmiar buforu. Prawidłowe wartości to od 1 do 4096 włącznie. Na kliencie ten atrybut definiuje maksymalny rozmiar buforu używanego przez kanał niezawodny do przechowywania komunikatów, które nie są jeszcze uznawane przez odbiorcę. Jednostka limitu przydziału jest komunikatem. Jeśli bufor jest pełny, dalsze operacje WYSYŁANIa są blokowane. W odbiorniku ten atrybut definiuje maksymalny rozmiar buforu używanego przez kanał do przechowywania komunikatów przychodzących, które nie zostały jeszcze wysłane do aplikacji. Jeśli bufor jest pełny, kolejne komunikaty są dyskretnie porzucane przez odbiornik i wymagają ponownego przesłania przez klienta.
uporządkowany	Wartość logiczna określająca, czy komunikaty są gwarantowane do odebrania w kolejności, w której zostały wysłane. Jeśli to ustawienie to `false`, komunikaty mogą pochodzić z zamówienia. Wartość domyślna to `true`.
reliableMessagingVersion	Prawidłowa wartość określająca ReliableMessagingVersion wersję WS-ReliableMessaging do użycia.

Elementy podrzędne

Brak

Elementy nadrzędne

Element	Opis
<Wiązania>	Definiuje wszystkie możliwości powiązania niestandardowego.

Uwagi

Niezawodne sesje zapewniają funkcje niezawodnych komunikatów i sesji. Niezawodna obsługa komunikatów ponawia próbę komunikacji po awarii i umożliwia zapewnienie dostarczania, takie jak określone w kolejności przybycie komunikatów. Sesje zachowują stan dla klientów między wywołaniami. Ten element również opcjonalnie zapewnia uporządkowane dostarczanie komunikatów. Ta wdrożona sesja może krzyżować się z pośrednikami w protokołach SOAP i transportowych.

Każdy element powiązania reprezentuje krok przetwarzania podczas wysyłania lub odbierania komunikatów. W czasie wykonywania elementy powiązania tworzą fabryki kanałów i odbiorniki, które są niezbędne do tworzenia stosów wychodzących i przychodzących kanałów wymaganych do wysyłania i odbierania komunikatów. Element reliableSession udostępnia opcjonalną warstwę w stosie, która może ustanowić niezawodną sesję między punktami końcowymi i skonfigurować zachowanie tej sesji.

Aby uzyskać więcej informacji, zobacz Reliable Sessions (Sesje niezawodne).

Przykład

W poniższym przykładzie pokazano, jak skonfigurować powiązanie niestandardowe z różnymi elementami kodowania transportu i komunikatów, szczególnie włączając niezawodne sesje, które utrzymują stan klienta i określają gwarancje dostarczania w zamówieniu. Ta funkcja jest skonfigurowana w plikach konfiguracji aplikacji dla klienta i usługi. W przykładzie pokazano konfigurację usługi.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service name="Microsoft.ServiceModel.Samples.CalculatorService"
               behaviorConfiguration="CalculatorServiceBehavior">
        <!-- This endpoint is exposed at the base address provided by host: http://localhost/servicemodelsamples/service.svc -->
        <!-- specify customBinding binding and a binding configuration to use -->
        <endpoint address=""
                  binding="customBinding"
                  bindingConfiguration="Binding1"
                  contract="Microsoft.ServiceModel.Samples.ICalculator" />
        <!-- The mex endpoint is exposed at http://localhost/servicemodelsamples/service.svc/mex -->
        <endpoint address="mex"
                  binding="mexHttpBinding"
                  contract="IMetadataExchange" />
      </service>
    </services>
    <!-- custom binding configuration - configures HTTP transport, reliable sessions -->
    <bindings>
      <customBinding>
        <binding name="Binding1">
          <reliableSession />
          <security authenticationMode="SecureConversation"
                    requireSecurityContextCancellation="true">
          </security>
          <compositeDuplex />
          <oneWay />
          <textMessageEncoding messageVersion="Soap12WSAddressing10"
                               writeEncoding="utf-8" />
          <httpTransport authenticationScheme="Anonymous"
                         bypassProxyOnLocal="false"
                         hostNameComparisonMode="StrongWildcard"
                         proxyAuthenticationScheme="Anonymous"
                         realm=""
                         useDefaultWebProxy="true" />
        </binding>
      </customBinding>
    </bindings>
    <!--For debugging purposes set the includeExceptionDetailInFaults attribute to true-->
    <behaviors>
      <serviceBehaviors>
        <behavior name="CalculatorServiceBehavior">
          <serviceMetadata httpGetEnabled="True" />
          <serviceDebug includeExceptionDetailInFaults="False" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>