理解WCF信頼性の高いセッションリトライ動作

Question

私は、WCF信頼性の高いセッションの信頼性に関するいくつかの質問を持っている：

1. は、WCFの再試行中にメッセージを再シリアライズしていますか？

   2. 1の場合は正しいです - それはメッセージパラメータを配置した後に起こるか、しないのですか？
   3. 2が正しい場合 - メッセージが確実に送信されたことを確認する方法はありますか？

私はまだリフレクターを介してそれを把握できませんでした。

UPD 1：私は、サーバーの戻り値を持つ、より興味があります。何が彼らに起こりますか？

UPD 2：メッセージパラメーター（正確にはサーバー応答）が破棄されるのはいつですか？適切な肯定応答が受け取られたときにそれは起こるか？

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 

は、私は（私は、このソリューションに来た理由のもう一つのSOFスレッドを持っている）サーバの応答を処分するためにそれを使用する必要があります。ここに は、私が処分のパラメータによって何を意味するかです。

UPD 3：私が解決しようとしている問題は、それがは私のサーバーの応答が最初にそれをシリアル化するアプリケーションの試みを配置されているだということです。私は他の場所で同じオブジェクトを再利用しないことを99％確信しています。 Stacktracesはここに投稿するのはかなり醜いです

Answer 1

いいえ、WCFはは、メッセージを再シリアライズしませありません。

これは（簡略化された）ものです：セッション中に、クライアントから送信された各メッセージがクライアントにバッファリングされています。デフォルトでは、32個のメッセージのための余地があります（これは調整可能で、サービス側にバッファもあります）。

メッセージがサーバーに送信され、正常に送信され、ディスパッチされた場合、サーバーは確認を送信し、クライアントはメッセージをバッファーから削除します。

ただし、クライアントが＃15と＃16のメッセージを送信してから＃16の確認を取得した場合（＃15ではない）、メッセージ＃15がバッファから再送信されます。

注文可能な配信が必要かどうか、クライアントがメッセージの送信を再試行する回数など、構成できるオプションがいくつかあります。

は、より多くの情報のため、これらの記事やブログ記事をチェックアウト：

• 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

を210

希望これは、物事に応答上のビット

UPDATE明確にするのに役立ちます。私は、参照（MSDN上の）最初の記事から取った：

我々は、応答を要求/応答 通信パターンを有すると仮定した場合 応答として と同じように確実に配信する必要があるため、応答側の は、 のイニシエータメカニズムを実装していなければなりません。 は、元の要求に対して実装した要求側のものと似ています。 要求側は 応答に対してアクセサーロールを再生し、 です。応答が失われた場合、 は応答側の によって再送される必要があります。したがって、それらもまた （および確認済み）にキャッシュする必要があります。したがって、 信頼できるメッセージングセッションの両端は、 は、アウトバウンド とインバウンドメッセージ用に別々のキャッシュを維持します。

はい、同じことが同様に適用されます。NetTCPやHTTPなどの双方向通信があれば問題なく動作しますが、記事で言及されているように、少し面倒です一方向操作の場合 - 詳細は記事を参照してください。

マーク