主にリポジトリ内のドキュメントを管理するために使用される WCF サービスがあります。
巨大なファイルをアップロード/ダウンロードできるように、MS のチャンキング チャネル サンプルを使用しました。
現在、サービスとの信頼できるセッションを実装しましたが、奇妙な動作が見られます。
これが私が使用しているタイムアウト値です。
this.SendTimeout = new TimeSpan(0,10,0);
this.OpenTimeout = new TimeSpan(0, 1, 0);
this.CloseTimeout = new TimeSpan(0, 1, 0);
this.ReceiveTimeout = new TimeSpan(0,10, 0);
reliableBe.InactivityTimeout = new TimeSpan(0,2,0);
次の問題があります
。 1. サービスが稼働していない場合、クライアントは OpenTimeout 後に切断されません。
テストクライアントで試してみました。
シナリオ 1: Reliable Session がない場合: 次の例外が発生します: net.tcp://localhost:8788/MediaManagementService/ep1 に接続できませんでした。接続の試行は、00:00:00.9848790 の期間継続しました。TCP エラー コード 10061: ターゲット マシンがアクティブに拒否したため、接続できませんでした 127.0.0.1:8788
OpenTimeout を 1 秒に設定したため、これは正しい動作です。
シナリオ 2: ReliableSession
の場合: 同じ例外が発生します。
net.tcp://localhost:8788/MediaManagementService/ep1 に接続できませんでした。接続の試行は、00:00:00.9692460 の期間継続しました。TCP エラー コード 10061: ターゲット マシンがアクティブに拒否したため、接続できませんでした 127.0.0.1:8788。
しかし、このメッセージは約 10 分後に表示されます。(SendTimeout の後だと思います) ここで、信頼できるセッションを有効にしたところ、クライアントの OpenTimeout = SendTimeout のように見えます。
これは望ましい動作ですか?
2: ReliableSession を使用して巨大なファイルをアップロードする際
の問題: 一般的な規則として、maxReceivedMessageSize、SendTimeout、および ReceiveTimeout に大きな値を設定する必要があります。
ただし、チャンキング チャネルの場合、データがチャンクで送信されるため、最大受信メッセージ サイズは重要ではありません。
そこで、Send と ReceiveTimeout に大きな値を設定しました。たとえば、10 時間です。現在、アップロードは順調に進んでいますが、(1) の動作により、サービスが起動していなくても、クライアント接続のタイムアウトに 10 時間かかるという副作用があります。
この行動についてのあなたの考えを教えてください。