問題タブ [duplex]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
wcf - WCFポーリングデュプレックスバインディングと非Silverlightクライアント
私はこれを理解するのにかなりの時間を費やしています。Silverlightクライアントに情報を提供する必要があるWCFサービスがありますが、これに参加できるようにするにはコンソールアプリケーションも必要です。コンソールアプリがアクセスできる追加のバインディングを指定するために、Web.Configがどのように表示されるかについてのヒントを誰かに教えてもらえますか?動作していると思うと、SLクライアントはメッセージを受信できません...
これが私の現在のWeb.Configです。
wcf - WCF コールバック (二重) サービスを同期的に使用する
外部 WCF コールバック (別名デュプレックス) サービスを使用する必要がある既存の WCF サービスがあります。双方向サービスは本質的に非同期ですが、元の WCF サービスの同期を維持する必要があります。これを行うためのよく知られたパターンはありますか?注意が必要な最も重要な落とし穴は何ですか?
私の現在の意図は、双方向サービスを呼び出してから、ManualResetEvent が発生するのを待つことです。コールバックがデュプレックスによって呼び出されると、イベントがリセットされ、待機中の操作が再開され、作業が完了します。
wcf - デュプレックスに net.tcp を使用して、Silverlight クライアントの接続がまだ有効であることを確認するにはどうすればよいですか?
私は、net.tcp と netTcpBinding を使用して WCF サービスをまとめ、Silverlight クライアントとの二重通信を取得しています。Silverlight アプリからサービスを呼び出すと、サービスは別のサーバーを呼び出し、WCF サービス クラスでコールバック メソッドを渡します。リモート サーバーは何度かコールバックし、そのたびに WCF サービスはコールバック チャネルを使用してデータを Silverlight クライアントに送信します。ほとんどの場合、すべてうまく機能します。
ユーザーが大きなリクエストを送信すると、多数のコールバックが既に機能した後で TimeoutException が発生します。(明らかに、これを防ぐために他の場所でやるべきことがいくつかありますが、まずサービスを強化したいと思います。)
Silverlight クライアントにコールバックする前に、何らかの「if (client.ConnectionState == faulted)」チェックを行うことを期待していましたが、接続の状態を保持するオブジェクトが見つからないようです。ありますか?私は間違った側からこれに近づいていますか?
これは、サービス net.tcp と duplex への私の最初のベンチャーです。家を引っ越したばかりで、WCF バイブルはまだ箱に入っています。どこか。:-) だから、私はいつもの背景を読むことができません。
どんな指摘もありがたく受け取るだろう。私の説明があまりにも厄介な場合に備えて、ここにいくつかの裸のコードがあります:
silverlight - Duplex Messaging (サーバー プッシュ) は WCF RIA で使用できますか?
Duplex Messaging (サーバー プッシュ) は WCF RIA で使用できますか?
ドメイン サービスの SOAP エンドポイントに適切なバインディング (PollingDuplexHttpBinding など) を指定する方法はないように思われます。
何か案は?
ありがとう。
wcf - WCFを介して大きなメッセージを送信できません
あらゆる種類のメッセージを送信するためにWCFを使用していますが、特にこのメッセージは約3200000バイトに加えて、いくつかの文字列とヘッダーです。ラージペイロードは、あらゆる面で模倣しようとした構成を持つ別のサービスを介してホストから取得されたシリアル化されたオブジェクトです。
パフォーマンスのためにnetTcpバインディングを使用しており、多くのコールバックを使用しています。クライアント側とサーバー側の両方で、見つけることができるすべてのオプションを最大レベルに設定しました。
クライアントで次の説明のないエラーメッセージが表示されます。
ソケット接続が中止されました。これは、メッセージの処理エラー、リモートホストによる受信タイムアウトの超過、または根本的なネットワークリソースの問題が原因である可能性があります。ローカルソケットのタイムアウトは「00:00:59.9979996」でした。
そして内面の脱出:
既存の接続がリモートホストによって強制的に閉じられました
トレースを実行すると、もう少し多くの情報が得られます(スタックトレースの最上位):
System.ServiceModel.Channels.SocketConnection.Write(Byte []バッファー、Int32オフセット、Int32サイズ、ブール値即時、TimeSpanタイムアウト)スタックトレースの最上位内部拡張:System.Net.Sockets.Socket.Send(Byte []バッファー、Int32オフセット、Int32サイズ、SocketFlags socketFlags)
スタックトレース内部例外の最上位:
System.Net.Sockets.Socket.Send(Byte []バッファー、Int32オフセット、Int32サイズ、SocketFlags socketFlags)
ペイロードをnullに設定した場合(3.2 MBのオブジェクトを送信しない場合)、メッセージは大騒ぎせずに通過します。
オブジェクトが別のサービスから発信されているという事実は、私の問題と関係がありますか?私の目には、問題はメッセージのサイズですが、構成のオプションを増やしても、これまでのところ役に立ちませんでした。
運が悪かったので、クライアントに設定しようとしました。ストリーミングを使用すると、リクエスト/レスポンスに切り替えたり、すべてのコールバックを削除したりします...
何か案は?
.net - 二重バインド WCF アプリケーションでドロップされたクライアントを処理する
Microsoft のサンプルであるDesign Patterns: List-Based Publish-Subscribe にほぼ従っている WCF アプリケーションで pub-sub モデルを使用しています。
このサービスは と の概念を提供しsubscribe()
ますunsubscribe()
が、クライアントが停止したりチャネルに障害が発生した場合の状況でクリーンアップを処理するためのベスト プラクティスは何ですか? 現在、クライアントがサブスクライブすると、現在InstanceContext
のClosed
およびFaulted
イベント (サービス ユーザーは PerSession インスタンス コンテキスト モードと netTcpBinding)にハンドラーをアタッチします。
OnClientLost
ただし、ハンドラーはクライアントのサブスクライブを解除するだけです。
- 上記は良い方法であり、クライアントが二重通信を切断したときにすべての状況を捉えるのに十分なだけの堅牢性を備えていますか? それとも、サービスがクライアントとの通信を試みた時点で発生した例外を処理し、クリーンアップを処理する必要がありますか?
- クライアント コールバック ハンドラのサブスクライブを解除するだけでなく、特に障害が発生した場合にさらにクリーンアップを実行する必要がありますか?
この質問は同様の質問を提起しますが、最終的には、サブスクライブおよび/またはサブスクライブ解除を呼び出すクライアント以外のケースに対する回答を提供しません
ありがとう
sockets - 単一のスレッドで TCP を介して全二重チャネルを実装する方法は?
私が書いているネットワーク ライブラリは、TCP ソケットを介してメッセージを送受信する必要があります。メッセージはいつでも送受信できます。つまり、全二重チャネルとして機能する必要があります。
send() を呼び出すメイン スレッドと、ほとんどが recv() 呼び出しでブロックされる専用スレッドの 2 つのスレッドを使用して、このようなシナリオを実装することができました。
私の質問は、単一のスレッドで同じシナリオを実装することは可能ですか? つまり、いくつかのコールバック関数を登録することによってですか?
補足として、このシナリオを C++、Java、および Python で実装する必要があります。
wcf - 長時間実行されるプロセスのWCFでの進行状況の通知-どのように?
クライアント/サーバーアプリケーションで長時間実行されるプロセスを処理する方法を設計および実装する必要があります。通常の長時間実行プロセスには2〜3分かかる場合があります。また、その間にUIに進行状況を報告し、UIの応答性を維持する必要があります。
これらを念頭に置いて、いくつかの解決策を考えました。
サーバー側プロセスを開始し、割り当てられたLRPID(長時間実行プロセスID)を返すプロセスを開始し、そのLRPIDを使用してクライアントから定期的にポーリングする1つの非同期要求。(長所:導入が簡単で、ファイアウォールが混乱することはありません。短所:エレガントでない、リソースを消費するなど)
デュプレックスバインディング(NetTcpBindingなど)を使用し、進行中にサーバーからのコールバックを開始します(Pro:エレガント、効率的、Con:展開の悪夢)
[あなたの提案???]
これについてどう思いますか?
c# - WCFコールバックタイムアウトとVisualStudioの壊滅的な障害
一種のばかげたエラーですが、これはサーバーサイドサービス(WCFデュプレックス)でクライアントを呼び出したいときに発生しました。
割り当てられたwcfコールバックタイムアウト00:01:00内にメッセージを転送できませんでした。信頼できるチャネルの転送ウィンドウに、使用可能なスペースがありませんでした。
また何かmysterious happened too
。ユーザーとパスワードが間違っている場合にサービスを呼び出したときのログインメソッドで、sender-callbackを見つけ、送信者のGetError
メソッドを呼び出して、「ユーザーが間違っています」などの論理エラーを表示します。これはうまく機能しますが、ユーザーとパスワードが正しく、アクセス権がある場合、そのエラーが発生します(他のすべてのクライアント側メソッドでも同じです。これらすべてのメソッドで、単純な文字列よりも多くのデータを送信し、geterrorを送信しました)。
編集2:ほとんどのコールバックメソッドで言うように、データコンテキスト(LINQ to SQL)データクラス(リストまたは単一行)のようなデータを送信していました。だから、これは私の問題かもしれません!
(しかし、WCFデュプレックスを使用し、コールバックメソッドでデータ構造体を送信するのはこれが初めてではありません。私はとても驚いています。)
また、そのエラーの後、私はこのエラーを受け取りました、
画面がサービスからのリクエストを処理できませんhttp:// server:15450/service.svc致命的な障害
編集3: サービス構成:
およびクライアント構成
詳細: .NET3.5とVisualStudio 2010を使用しています。また、クライアント側でタイムアウトが発生した後も、同じエラーが発生しましたwith 00:01:00 Time
。なぜこれが起こったのですか?
wcf - WCFデュプレックスチャネル、要求と応答の分離
私は、SOAP Webサービスの「非同期」モード、「二重」モード、または「コールバック」モードとさまざまに呼ばれるものを使用する必要があるプロジェクトを検討しています。このモードでは、サービスの呼び出し元はSOAPヘッダーで「reply-to」アドレスを提供し、サービスはHTTP応答で呼び出しの出力を返す代わりに、この「reply-to」への個別のHTTP接続を作成します。 "アドレスを指定して、応答メッセージを投稿します。これは通常、次のように、CompositeDuplexBindingを使用してWCFで実現されます。
これにより、呼び出しごとに1つではなく2つのHTTP接続が発生します。1つはクライアントからサービスに、もう1つはサービスからクライアントに戻ります。サービス実装の観点からは、何も変更されません。インターフェイスメソッドを実装するメソッドがあり、要求を受け取って応答を返します。素晴らしい、これは私がほとんど必要としているものです。
私の状況では、リクエストとレスポンスは数分から数日まで何でも分けることができます。要求と応答を分離し、後で応答するのに十分な情報が得られるまで(または、特定の状況では決して応答しないまで)状態(メッセージ、応答URIなど)を「保存」する方法が必要です。
必要なばかげたタイムアウト値(有効なものとして受け入れられている場合でも)とともに、メソッドを一度に最大数日間基本的に「一時停止」することにそれほど興奮していませんが、どうすればよいかわかりません。このようなシステムを組み合わせます。
完全に明確にするために、私は標準化団体によって提供される一連の標準を実装しているので、SOAPメッセージのセマンティクスを変更したりプロトコルの実装を変更したりする柔軟性がありません。この種の相互作用は、ReplyToヘッダーがWS-Addressingに実装されたときに意図されていたものとまったく同じです。
どうしますか?おそらく、Workflow Foundationはこの種のことを可能にしますか?