2

クライアントが継続的にループしてデータをチェックする必要なく、サーバーからクライアントに継続的に (ストリーミング) データを送信したいと考えています。これがオブザーバーのデザインパターンであると信じるのは正しいと思いますか? これはどのように可能ですか？

誰かが私がググることができるもののリストを提供してくれませんか? オブザーバーパターンのアスペクトはどのように実装されていますか?

ありがとう

4

3 に答える 3

3

オブザーバーのデザインパターンは、あなたが説明しているものとは少し異なります。

ここに画像の説明を入力してください

各オブザーバーは「監視可能な」オブジェクトによって通知されることに注意してください。したがって、データを継続的にストリーミングしているサーバーがある場合、サーバーがあなたに「通知」することを期待し、サーバーがあなたに通知することを期待しますか？それがあなたに送るすべてのパケット？パケットのすべてのチャンク？

つまり、いいえ、クライアント/サーバーアプリケーションにオブザーバーパターンを実装することはできません。サーバーがクライアントアプリでnotifyメソッドを呼び出す（簡単な）方法はありません。クライアントが切断されても、オブザーバブルから登録解除されることはありません。

質問に戻りましょう...アーキテクチャによって制限されます。ブロッキングソケット（tcp / udp）はすべて、データを受信するまでブロッキングすることで機能します。データを受信したら、さらにデータを継続的に取得するには、ループしてもう一度受信を呼び出す必要があります。別の方法は、非同期ソケットを使用することです。

非同期ソケット通信は、おそらくオブザーバーパターンに近づくのと同じくらい近いです。さらに、ストリーミングデータがあり、UDPはストリーミングデータ用に特別に設計されているため、UDPプロトコルを使用する必要があります。（UDPの信頼性が低いために）パケットを見逃したくない場合は、信頼性の高いUDPを使用できます。

于 2011-07-30T13:57:38.747 に答える
0

私が理解しているように、ここでの主な懸念は、サーバーからのデータを待っているクライアントアプリケーションをブロックしてはならないということです。そのために、ソケット イベントに作用する 1 つのスレッドを作成できます。クラスのコンテキストをこのスレッド モジュールに登録すると、データが受信されるたびに、このスレッド モジュールは登録されたコンテキストを使用してコールバック (通知) を行うことができます。

于 2011-07-30T14:46:21.350 に答える
0

通信プロトコルがまったく異なるため、クライアント/サーバーのユース ケースにオブザーバー パターンを実装することはできません。（RPCが適しているかもしれませんが、TCPを使用しているため）

とにかく、できることは、データを受信するための専用の TCP クライアントを持つことです。それがこの TCP クライアントであり、内部クラスは一緒に Observer パターンを実装できます。これにより、クラスはデータを待機 (ポーリング) する必要がなくなります。

シャッシュ

于 2011-07-30T14:09:31.770 に答える