Zrozumienie WCF niezawodny sesja ponawiania zachowanie

Question

Mam kilka pytań na temat WCF niezawodnego niezawodności sesji:

1. Czy WCF ponownej serializacji wiadomość podczas próby ponawiania?

   2. Jeśli 1 jest poprawny - czy dzieje się to po usunięciu parametrów komunikatu, czy nie?
   3. Jeśli 2 jest poprawne - czy istnieje jakiś sposób identyfikacji wiadomości wysłanej na pewno?

Nie mogłem jeszcze tego wykombinować przez reflektor.

UPD 1: Jestem bardziej zainteresowany wartościami zwracanymi przez serwer. Co się z nimi dzieje?

UPD 2: Kiedy wyświetlane są parametry komunikatu (a dokładniej - odpowiedź serwera)? Czy to się dzieje, gdy odbierane są odpowiednie pakiety? Oto co mam na myśli parametrów rozstrzygających:

at MyNamespace.MyReply.Dispose() 
    at System.ServiceModel.Dispatcher.MessageRpc.DisposeParametersCore() 
    at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessageCleanup(MessageRpc& rpc) 
    at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc) 
    at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc) 
    at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet) 
    at System.ServiceModel.Dispatcher.ChannelHandler.DispatchAndReleasePump(RequestContext request, Boolean cleanThread, OperationContext currentOperationContext) 
    at System.ServiceModel.Dispatcher.ChannelHandler.HandleRequest(RequestContext request, OperationContext currentOperationContext) 
    at System.ServiceModel.Dispatcher.ChannelHandler.AsyncMessagePump(IAsyncResult result) 
    at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result) 
    at System.ServiceModel.AsyncResult.Complete(Boolean completedSynchronously) 
    at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result) 
    at System.ServiceModel.AsyncResult.Complete(Boolean completedSynchronously) 
    at System.ServiceModel.Channels.InputQueue`1.AsyncQueueReader.Set(Item item) 
    at System.ServiceModel.Channels.InputQueue`1.Dispatch() 
    at System.ServiceModel.Channels.InputQueueChannel`1.Dispatch() 
    at System.ServiceModel.Channels.ReliableReplySessionChannel.ProcessSequencedMessage(RequestContext context, String action, WsrmSequencedMessageInfo info) 
...stack continues 

muszę używać go do dysponowania odpowiedź serwera (mam inny wątek SOF, dlaczego przyszedłem do tego rozwiązania).

UPD 3: Issue Próbuję rozwiązać jest to, że wydaje że moja odpowiedź serwera jest umieszczony na początku, a następnie aplikacja próbuje go serializacji. Mam 99% pewności, że nie używam tego samego obiektu w innym miejscu. Stacktraces są dość brzydkie i duże, aby je tutaj opublikować.

Answer 1

Nie, WCF robi , a nie ponownie rozpowszechnia wiadomość.

Co się dzieje (jest uproszczona): podczas sesji każda wiadomość wysyłana z klienta jest buforowana na kliencie. Domyślnie jest miejsce na 32 wiadomości (można to zmienić, a także jest bufor po stronie usługi).

Wiadomość jest wysyłana na serwer, a jeśli zostanie odebrana i wysłana, serwer wyśle ​​potwierdzenie, a klient usunie wiadomość z bufora.

Jeśli jednak klient wysłał wiadomość nr 15 i nr 16, a następnie otrzyma potwierdzenie dla numeru 16 (ale nie dla numeru 15), to komunikat nr 15 zostanie ponownie wysłany z bufora.

Istnieje kilka opcji, które można skonfigurować, np. Czy chcesz zamówić przesyłkę, ile razy klient powinien ponowić wysyłanie wiadomości i tak dalej.

Wyjazd tych artykułów i blogu uzyskać więcej informacji:

• Introduction to Reliable Messaging with the Windows Communication Foundation
• WCF: Reliable Message Delivery
• How does Reliable Messaging work
• WCF Sessions and Reliable Messaging
• WCF Top To Bottom Screencast; Reliable Messaging

Nadzieja to pomaga wyjaśnić sprawę nieco

aktualizację na odpowiedzi: zaczerpnięte z pierwszego artykułu (na MSDN) Ja odwołanie:

Jeśli założymy o żądanie/odpowiedź wzór komunikacji, odpowiedź musi być dostarczany tak samo niezawodnie, jak żądanie, a zatem strona odpowiadająca musi wdrożyć mechanizm inicjujący , który jest bardzo podobny do tego, który żąda strona realizuje dla pierwotnych żądań. Z kolei stroną żądającą jest w roli akceptora odpowiedzi . Jeśli odpowiedzi zostaną utracone, muszą one zostać wysłane ponownie przez stronę odpowiadającą , a zatem muszą one również zostać zbuforowane w pamięci podręcznej (i potwierdzone). Obydwa końce niezawodnej sesji przesyłania wiadomości przechowują zatem oddzielne pamięci podręczne dla wychodzących i wiadomości przychodzących.

Więc tak, to samo odnosi się do odpowiedzi, a także - co działa dobrze tak długo, jak mamy dwukierunkową komunikację jak na NetTCP lub HTTP - jak wspomniano w artykule, to robi się nieco trudniejsze w przypadku operacji jednokierunkowej - szczegółowe informacje znajdują się w artykule.

Marc