2

ユーザーがログインし、それによって何らかのイベント (この場合はアラーム) を登録する Web アプリケーションを実装することになっています。アラームが発生すると、サーバーはアラームをすべてのクライアントにプッシュする必要があります。

現時点で私が使用している

  • クライアント側の GWT
  • サーバー側の桟橋

Jetty Continuations を使用してサーバー プッシュを実装することは良い考えですか? 私の要件は次のとおりです。

  • クライアントの数は非常に少ない (<20) が、将来的に増加する可能性がある
  • アラームが失われてはなりません (つまり、クライアントがダウンした場合でも、アラームを見逃してはなりません)
  • クライアントがダウンした場合、他のクライアントにそのことを通知する必要があります (または、少なくとも管理者はメールなどで何らかの通知を受け取る必要があります)。
4

2 に答える 2

2

Comet (Jetty Continuations など) を使用する主な理由は、ポーリング頻度を減らすことができるためです。つまり、クライアント側から頻繁にポーリングを使用することで、Comet がなくても同じことを実現できます。どの代替手段を選択するかは、アプリケーションの特性によって異なります。それに応じて、各代替手段の効率が高くなったり低くなったりする可能性があります。

あなたの場合、クライアントがダウンしたときに通知が必要なため、頻繁にポーリングを使用することは理にかなっています。コメット (ロング ポーリング) は、このタスクにはあまり適していません。その原理により、クライアントが新しい要求を送信するまでに長い時間がかかることがあります。そして、サーバーがクライアントがまだ生きていることを知ることができる唯一の方法は、新しいリクエストを受信することです (Web サーバーは、Comet であるかどうかに関係なく、クライアントにリクエストを送信できないことに注意してください)。

于 2011-01-25T12:11:53.040 に答える
1

要件は、アラームが失われてはならないことを示しており、長いポーリングまたは頻繁なポーリングよりも複雑なソリューションを意味します。

クライアントはサーバーに確認メッセージを送信する必要があります。これは、アラーム メッセージが到着した直後にユーザーがアプリケーションを閉じる可能性があるためです。ユーザーはそのアラームを失う可能性があります。また、ユーザーはアラーム メッセージをクリックしてサーバーを承認する必要があります。クライアントが ack メッセージを送信しない場合は、アラームが失われたと見なすことができます。

確認アルゴリズムを使用したロングポーリングは、問題を解決するための私の選択です..

于 2011-01-25T13:06:11.243 に答える