Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Definiuje ustawienie dla WS-Reliable Messaging. Po dodaniu tego elementu do powiązania niestandardowego wynikowy kanał może obsługiwać dokładnie jednokrotne gwarancje dostarczania.
<configuration>
<system.serviceModel>
<bindings>
<customBinding>
<binding>
<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.
Attributes
| Attribute | Description |
|---|---|
| potwierdzenieInterval | Element TimeSpan zawierający maksymalny interwał czasu, przez który kanał będzie czekać, aby wysłać potwierdzenie dla komunikatów odebranych do tego momentu. Wartość domyślna to 00:00:0.2. |
| flowControlEnabled | Wartość logiczna wskazująca, czy aktywowano zaawansowaną kontrolę przepływu, specyficzną dla firmy Microsoft implementację sterowania przepływem na potrzeby WS-Reliable obsługi komunikatów. Wartość domyślna to true. |
| inactivityTimeout | Element TimeSpan określający maksymalny czas trwania kanału, który umożliwi innej osobie komunikacji, aby 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 przechowywania nieaktywnej sesji. Jeśli dłuższy czas przejdzie bez działania, sesja zostanie przerwana przez infrastrukturę i błędy kanału. Nuta: Aplikacja nie musi okresowo wysyłać komunikatów w celu zachowania aktywności połączenia. |
| maxPendingChannels | Liczba całkowita określająca maksymalną liczbę kanałów, które mogą oczekiwać na zaakceptowanie odbiornika. Ta wartość powinna należeć do przedziału 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, a aplikacja zdalna spróbuje ustanowić nową niezawodną sesję, żądanie zostanie odrzucone i operacja otwierania, która spowodowała wyświetlenie tego błędu. Ten limit nie ma zastosowania do liczby oczekujących kanałów wychodzących. |
| maksymalnaLiczbaPrób | 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ę Send 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 do adresata 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 ponownie przesyła komunikat. 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 w celu określenia, kiedy należy ponownie przesłać, 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 ponownej transmisji jest dostosowywany zgodnie z obliczonym czasem rundy i wynikowym odcinku czasu, który te próby są różne. Dzięki temu czas ponownej komunikacji dynamicznie dostosowuje 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 niezawodny kanał do przechowywania komunikatów, które nie są jeszcze potwierdzane przez odbiornik. Jednostka limitu przydziału jest komunikatem. Jeśli bufor jest pełny, dalsze operacje SEND 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, dalsze komunikaty są dyskretnie porzucane przez odbiornik i wymagają ponownego przesłania przez klienta. |
| uporządkowany | Wartość logiczna określająca, czy komunikaty mają gwarancję nadejścia 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ść z ReliableMessagingVersion tego określa WS-ReliableMessaging wersji, która ma być używana. |
Elementy podrzędne
Żaden
Elementy nadrzędne
| Składnik | Description |
|---|---|
| <wiążący> | Definiuje wszystkie możliwości powiązania niestandardowego. |
Uwagi
Niezawodne sesje zapewniają funkcje niezawodnej obsługi komunikatów i sesji. Niezawodna obsługa komunikatów ponawia próbę komunikacji w przypadku awarii i umożliwia określenie gwarancji dostarczania, takich jak dostarczenie komunikatów w kolejności. Sesje zachowują stan dla klientów między wywołaniami. Ten element umożliwia również opcjonalne dostarczanie uporządkowanych komunikatów. Ta wdrożona sesja może przekraczać protokoły SOAP i pośredników 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 kanałów wychodzących i przychodzących 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).
Example
W poniższym przykładzie pokazano, jak skonfigurować niestandardowe powiązanie 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 kolejności. 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>