「伝統的」というのは、すべてのクライアントができる限り頻繁にサーバーをハンマーで打つことを意味するのであれば、私はアーキテクチャレベルで支援できます。
適切な設計は、サーバーがこのグリッドのどこに位置するかによって異なります。
Control \ Resources : Sufficient | Insufficient
Customizable : SC | IC
Untouchable : SU | IU
SC:サーバーにオブザーバーパターンに従うようにします。クライアントがオブザーバーとして登録できるようにします。
IC:プロキシシステムのみがサーバーに登録できるようにします。クライアントはプロキシに登録します。
SU:プロキシシステムのみがサーバーをポーリングできるようにします。クライアントはプロキシに登録します。
IU:プロキシシステムのみがサーバーをポーリングできるようにします。クライアントはプロキシに登録します。
オブザーバーパターンに従うプロキシは、カスタマイズとリソースの両方の問題を解決できます。これは、オブジェクト間で行われるのと同じように、インターネットを介して同様に機能します。登録すると、何かが発生したときに呼び出されるように求められます。ポートをリッスンすると、呼び出す準備が整います。ajax、REST、UDPなど。
ポーリングの問題は、オブザーバーが呼び出しが発生するタイミングを制御しているが、状態がいつ変化するかを認識していないため、多くの不要な呼び出しを行うことです。これは、特にオブザーバーが多い場合にリソースを消費します。ポーリングを処理するための鍵は、できるだけ早く、状態の変化点からオブザーバーへの呼び出しの方向を取得することです。その後、必要なときに呼び出しが行われます。そうでない場合はそうではありません。
この方法でポーリング呼び出しを行う場合:
これらのいずれも、変更を検出するためのより良い方法です。
SC:サーバー===>多くのオブザーバー
IC:サーバー===> 1つのプロキシ===>多くのオブザーバー
SU:サーバー<=== 1つのプロキシ===>多くのオブザーバー
IU:サーバー<=== 1つのプロキシ===>多くのオブザーバー