net.tcp DuplexChannel を使用した WCF セルフホステッド サービスがあります。サーバーで次を実行して、クライアントを切断します。
((ICommunicationObject)client.CallbackChannel).Close();
これは正常に動作しますが、切断されたことをクライアントで検出するにはどうすればよいですか?
コールバックの InstanceContext とサーバーへのチャネルの両方で、Closed イベントと Faulted イベントに接続しました。
InstanceContext callback = new InstanceContext(callbackImp);
callback.Closed += new EventHandler(callback_Closed);
と
((ICommunicationObject)Channel).Closed += new EventHandler(Channel_Closed);
しかし、何も機能しません。通知が来ることはありません。私が現在使用している回避策は、代わりにクライアント側からの切断をトリガーするメソッドをコールバックに含めることです。しかし、私はむしろこのようにはしません。特に、ユーザーが切断するまでサーバーを待たせたくありません。
編集
クライアント側から切断するときに、IsTerminating = true でマークされたサービス コントラクトでメソッドを実行することに気付きました。
[OperationContract(IsTerminating = true)]
void Disconnect();
コールバック契約でも同じだと思いましたか？同じメソッドをコールバックに追加しようとしましたが、サーバーの観点からコールバックチャネルを終了しましたが、クライアント側でまだ通知を受けていません...奇妙な
編集
私はこれについていくつかのより多くの情報を見つけました：
サーバーがコールバック チャネルを中止すると、障害がクライアントに戻り、クライアントに障害が発生し、クライアントで Faulted イベントが発生します。
サーバーがコールバック チャネルを閉じても、クライアントが閉じるまでセッションは開いたままです。
クライアントがチャネルを閉じると、Closed イベントが表示されます。
このステートメントによると、Close イベントは、サーバーからのコールバック チャネルを閉じるだけではトリガーされず、クライアントもそれを閉じる必要があります。したがって、コールバックの切断メソッドを終了する際に、クライアントで Close を実行できます。または、コールバック サーバー側で Abort メソッドを使用し、コールバックで Disconnect メソッドを使用してスキップすることもできます。どちらが好きかは正直わかりません。うーん。
編集
私はアボートアプローチを採用しました。これは最も論理的な方法のようで、非常にうまく機能します。クライアントは、コールバック インスタンス コンテキストの Faulted イベントで通知されます。良い。