問題タブ [duplex]

Silverlight クライアントと.NET 3.5 WCFサービスを使用してWCF二重サービスを使用しています。

私が持っているシナリオは次のとおりです。サーバーからクライアントへの二重プッシュOneWay操作中に、クライアント通知ハンドラーで例外が発生した場合、チャネルはサイレントに失敗するため、サーバーからのそれ以上の二重呼び出しはタイムアウトして失敗します。（ここで説明されているように 一方向の操作と例外）

私の質問:

1. で装飾しFaultContract、OneWay OperationContractクライアントで例外をラップして、チャネルの障害を防ぐことはできますか?
2. そうでない場合、サーバーからの二重プッシュ中にクライアントで発生した例外をキャッチする他の方法は何でしょうか?

HTTPS を使用するように Silverlight アプリと双方向 WFC サービスを構成するにはどうすればよいですか? 現在、HTTP を使用するとすべてが機能しますが、クライアントが HTTPS を使用してサイトにアクセスするとすぐに、サービス内でのコールバックの作成が失敗します。構成ファイルを変更する必要があると思いますが、何に設定すればよいかわかりません。

これが私の現在の設定です：

Silverlight アプリから、次のようにクライアント プロキシを作成します。

ありがとう...

2008 年以降、エコー キャンセルが ADO​​BE に要求され、何もしていないということはありません。彼らは 6 月に 10.3 プレーヤーでこの機能をリリースすると (3 か月前に) 約束しました。

今すぐ解決策が必要です。6 月まで待ちきれません。これに対してサーバー側のソリューションを試した人はいますか? 私はこの会社を見つけました: http://www.solicall.com/index.html、彼らはイスラエルにあり、私は彼らに連絡し、私は彼らの返事を待っています。

基本的に、2 つのフラッシュ クライアント間で全二重オーディオ通信が必要です。ユーザーがヘッドセットなしでエコーなしで話すことができる限り、FMS または Red5 (またはその他のテクノロジ) を使用できます。

同じ主題についていくつかの質問があるのを見ましたが、それらのほとんどはクライアントのソリューションに焦点を当てており、残念ながら解決策はありません.

提案/アイデアはありますか？わかりました。

Silverlight 4 アプリケーションが接続する二重サービスの良い例に興味があります。その中に本があれば喜んで手に入れます。

私はここにあるMSDNのものを調べましたが、うまく従わなかったり、機能したりしませんでした。

私の問題のいくつかを説明するかもしれないこれを見つけました-MSDN投稿

コンソールアプリケーション内でホストされるwcfサービスを作成しました。次に、サービスと対話するクライアントがあります。

クライアントとサービスは私のマシンで正常に動作します。

クライアントを別のコンピューターに移動すると、動作させることができますが、サーバーとクライアントマシンの両方でファイアウォールをオフにする必要があります（サービスが最終的に通信する必要があるファイアウォールポートを開くだけでこれを修正できると想定しています） ？）しかし、スカイプをオフにする必要があります。そうしないと、「URLを登録できませんでしたhttp：// +：80 /temporary_Listen_Address / ......」「によって使用されているため、プロセスはファイルにアクセスできませんでした。別のプロセス」。

クライアントのベースアドレスの変更についていくつか読んだことがありますが、これを動作させることができませんでした。しかし、私は何か他のものが欠けているかもしれません。自分のマシンとは別のマシンに移動するときに、クライアント構成のエンドポイントアドレスを変更する必要があると感じていますが、これによりセットアップが壊れたため、変更しませんでした。

これが私の設定です。

サーバ

クライアント

敬具

灰

WCFデュプレックス（チャットサービス| SMSサービス）でミニプロジェクトを開発した後、私はおそらく正しくないポイントを取得しました!!

デュプレックス理論は優れていて便利だと思いましたが、Wcfデュプレックスの使用には多くの問題があります。（信頼できるセッション、タイムアウト例外、クライアントアドレス-サーバー側の管理、クライアント側のプロキシ管理など）

私は間違っていると思いますか？私は何かが恋しいですか？

詳細については、tcpBindingではなくwsDualHttpBindingを使用しました。

WCFデュプレックスコールバックを使用してクライアントサービスアプリケーションを作成しています。このサービスは、接続されているすべてのクライアントにメッセージを送信します。接続されているすべてのクライアントを辞書に保存しています。クライアントにメッセージを送信する前に、クライアントが異常にシャットダウンしたかどうかを確認したいと思います（ネットワークの切断、電源オフ）。

@marc_s：辞書で接続されているクライアントの通信状態をチェックするCheckCallbackChannelsメソッドを作成しました。

しかし、ここでは、障害のあるクライアントにも接続されている状態を取得します。

これについては以前にある程度投稿しましたが、数日読んだ後、WCF の理解が深まり、作業を開始する前に少しフィードバックを得たいと思います。

基本的に、サーバー/クライアント システムを開発する必要があります。「サーバー」アプリケーション (c# ネット コンソール アプリ) は、MySQL データベース、すべてのソフトウェア インストール パッケージ、およびローカルで必要なその他すべてを備えたマシン上で実行されます。「クライアント」アプリケーション (c# ネット コンソール アプリ) は残りのマシンで実行され、サーバー ソフトウェアへの直接接続を維持します。管理者は Web フロントエンドを使用して、ソフトウェア パッケージをクライアントにインストールしたり、新しいサービスを作成したりできます。

私たちはすべてのマシンを所有しており、とにかくそれらを構成する必要があるため、サーバー プッシュは問題ではありません。ファイアウォールやその他の NAT 設定について心配する必要はありません。動作に必要なポートを入力して開くだけでよいからです。

WCF について最初に混乱したのは、「WCF サービス」をサーバーに関連付けたことです。ただし、操作の大部分は実際には「WCF サービス」で実行されるため、これが私の論理です。

1）「クライアント」アプリケーションを実際に「WCFサービス」にして、公開された機能が実際に適切なマシンで実行されるようにします。

2）「サーバー」アプリケーションを実際に「WCFクライアント」にして、ここからすべての指示/コマンドを発行し、戻り値を使用してデータベースなどを更新します。

これは従うべき適切な方法でしょうか、それとも WCF Duplex (一見すると非常に紛らわしいように見えます) を調べる必要がありますか、それとも raw ソケットから始める必要がありますか?

このようなWCFサービス契約があるとします

サービスの実装はInstanceContextMode.Single設定されてInstanceContextMode おり、ICallback1次のようなものです

クライアント側では、 ICallback1 を実装するクラスを持つことができます

そして、このようなクライアントサービス参照を作成します

これは正常に動作します。問題は、コールバックに関心のないクライアントがいくつかあることです。そのため、そのようなクライアントのコールバック インターフェイスを実装する必要はないと考えたので、これを試しました。

と

両方とも、parameter cannot be null. 私の質問は、クライアントがコールバックに関心がない場合、コールバック オブジェクトを渡さずにサービス参照を作成するにはどうすればよいかということです。唯一の要件は、すべてのクライアントが同じサービスと通信する必要があることですが、それ以外の場合はサービスを再構築できます。何かご意見は ？

編集：

SessionMode = SessionMode.Allowed代わりに ServiceContractも試し ましSessionMode.Requiredたが、どちらも役に立ちませんでした。

サーバーがインターネットを介して多くのクライアントに同じメッセージを送信するクライアントサーバーアーキテクチャを実装する必要があります。約5分ごとに1つのメッセージを送信する必要があります。メッセージは5KBを超えません。接続されている多数のクライアント（50.000〜100.000）に拡張できるソリューションが必要です

私はたくさんの解決策を検討しました：

• TCPソケット

• UDPマルチキャスト

• WCF httpデュプレックスサービス（comet）

UDPソリューションは、同じネットワーク上のクライアントにのみ適したソリューションであり、インターネット上では機能しないため、破棄する必要があると思います。多くのクライアントが接続されている場合、WCFマルチキャストがボトルネックになることをどこかで読みましたが、パフォーマンス統計を示すドキュメントがどこにも見つかりません。Tcpソケットは、私が選択するソリューションのようです。についてどう思いますか？私は正しいですか？

UDPがインターネットで機能しないと言うとき、私は確かに間違っています...マルチキャストをサポートするには、ネットワークに適切に構成されたルーターが必要であると指摘する記事を読んだので、これを考えました...udpポートのマルチキャストを読みました範囲とそれがローカルであることを意味すると思った。代わりに、224.0.0.1〜239.255.255.255（クラスDアドレスグループ）の範囲にインターネット経由で到達できます。

私の場合、信頼性は重要なポイントではないことを考えると、udpマルチキャストは良い選択です。.netフレームワークは、これを実現するために非常に役立つクラスを提供します。UdpClientを簡単に起動し、2行のコードでマルチキャストアドレスでデータの送信を開始できます。クライアント側では、それは本当に簡単です。私が必要としていることを正確に実行するUdpSingleSourceMulticastClientクラスがあります。信頼性とセキュリティに関係することについては、.netフレームワークには、DoS攻撃、DNS再バインド攻撃、およびリバーストンネル攻撃を処理するスマートでシンプルな方法があります。これについては、http：//msdn.microsoft.com/en-us/library/ee707325で説明しています。 （v = vs.95）.aspx