クライアント/サーバーアプリケーションでは、サーバーとの通信に単一のデュプレックスWCFチャネルを使用できるようにする必要があります。これは、クライアントアプリケーションの実行に厳密には必要ではないが、サーバーにステータスを報告するために望ましいバックグラウンド接続の一種です。 。とにそれぞれPing()呼び出しとEcho()コールバックがIServerContractありIClientContractます。
class ServerProxy : System.ServiceModel.DuplexClientBase<IServerContract>パススルーメソッドを使用して実装しbase.InnerChannelます。
var proxy = new ServerProxy(...)クライアントで作成した場合、呼び出しproxy.Ping()を開始するだけで、WCFは最初の呼び出しの接続を自動的に開き、直後に操作呼び出しを実行します。ただし、チャネルの初期化と認証のため、最初の呼び出しには常に最大10秒かかります。（私はWindows認証、メッセージベースのセキュリティ、EncryptAndSignを使用しています。）後続の呼び出しはより高速です。
この10秒は避けられないと思いますが、通常、クライアントがサーバーを最初に呼び出す前に、この初期化が行われる可能性がある時間があります。そのため、の自動オープン機能を待つのではなく、DuplexClientBaseへの呼び出しでチャネルを早期に開きますproxy.InnerDuplexChannel.Open()。（proxy.Open() 例外をスローし、この間接参照はそれを回避しているようです。）
残念ながら、クライアントからサーバーへのチャネルを認証しても、サーバーからクライアントへのコールバックチャネルは認証されません。代わりに、サーバーからクライアントへの最初の呼び出しにも約10秒かかります。私はnetTcpバインディングを使用しているので、これには驚いていますが、今のところ予想されていると思います。
コールバックチャネルをプリエンプティブに開くにはどうすればよいですか？
代わりにクライアントに何らかのメソッドを呼び出すように要求することもできますが、Login()ユーザーコードが接続されたクライアントを認識できるようになる前に、WCFが厳密に操作を要求する必要があるとは思いません。
ヒント（？）：このコードは、WCFパイプライン/ライフサイクルの中で、サーバーがクライアントに接続されたイベントに対して（および操作メッセージが送信される前に）カスタムアクションを実行する機会がある場所に配置する必要があると思います。この統合ポイントは、これまでのところ私にはわかりませんでした。