5

WCFの信頼できるセッションの信頼性についていくつか質問があります。

  1. WCFは、再試行中にメッセージを再シリアル化しますか？

    2. 1が正しい場合、メッセージパラメータが破棄された後に発生しますか？
    3. 2が正しい場合、メッセージが確実に送信されたことを識別する方法はありますか？

私はまだリフレクターを介してそれを理解することができませんでした。

UPD 1：サーバーの戻り値にもっと興味があります。彼らはどうなりますか？

UPD 2：メッセージパラメータ（正確には-サーバー応答）はいつ破棄されますか？適切なackが受け取られたときにそれは起こりますか？パラメータを破棄するとは、次のようになります。

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％確信しています。スタックトレースはかなり醜く、ここに投稿するのは大きいです。

4

1 に答える 1

7

いいえ、WCF はメッセージを再シリアル化しません。

何が起こるか (簡略化): セッション中、クライアントから送信される各メッセージはクライアントでバッファリングされます。デフォルトでは、32 個のメッセージ用のスペースがあります (これは微調整できます。また、サービス側にもバッファーがあります)。

次に、メッセージがサーバーに送信され、問題なく送信されてディスパッチされると、サーバーは確認を送信し、クライアントはメッセージをバッファーから削除します。

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

順序付けされた配信が必要かどうか、クライアントがメッセージの送信を再試行する回数など、構成できるオプションはかなりあります。

詳細については、これらの記事とブログ投稿をご覧ください。

これが物事を少し明確にするのに役立つことを願っています

応答の更新: 私が参照した最初の記事 (MSDN) から取得:

Request/Response 通信パターンがあると仮定すると、応答は要求と同じくらい確実に配信される必要があるため、応答側は、要求側が元の要求に対して実装するものと非常によく似たイニシエーター メカニズムを実装する必要があります。要求側は、応答の受け入れ側の役割を果たします。応答が失われた場合は、応答側が再送信する必要があるため、応答もキャッシュ (および確認) する必要があります。したがって、信頼できるメッセージング セッションの両端は、送信メッセージと受信メッセージに対して個別のキャッシュを維持します。

そうです、同じことが応答にも当てはまります - NetTCP や HTTP などの双方向通信がある限り問題なく動作します - 記事で述べたように、一方向の場合は少しトリッキーになります操作 - 詳細は記事を参照してください。

マルク

于 2009-10-07T12:27:06.930 に答える