java - midlet のスレッドセーフチェック変数

Question

Javaで書かれたサーバーに接続するクライアント側のj2meでゲームをプログラミングしています。このゲームにはチャット機能がありますが、副次的な機能です。

サーバーに接続するすべての midlet に対して、サーバー ゲーム スレッドが生成されます。これらのスレッドは、サーバー内の一連の構成ファイルに順番に同期して書き込むことができるように、それらの間で対話します。ここで、チャット メッセージがいずれかの midlet に書き込まれると、ソケット通信を管理するクライアント側スレッドに渡され、サーバーに送信されます。サーバーでは、同じゲームの他のすべてのプレイヤーに通知され、チャット メッセージがすべてのプレイヤーに中継されます。したがって、すべてのサーバー スレッド (ただし、最初にメッセージを送信したユーザーのスレッド) は、対応するクライアント スレッドにメッセージを送信します。

これが私の質問です。新しい着信メッセージがあることを各 midlet に通知するにはどうすればよいですか?

クライアント側の通信スレッドをポーリングして、新しいメッセージがあるかどうかを確認するスレッドを作成することを考えました。しかし、それでは、途中で中断せずに、どのようにミッドレットから知ることができますか? 理想的には、クライアント側の通信スレッドにある文字列を直接読み取りたいのですが、その文字列が書き込まれている可能性があるため、それにアクセスして同期するスレッドが必要です。

どなたか手を貸していただけませんか？進め方がよくわかりません。これはかなり簡単なはずです...

前もって感謝します

Answer 1

残念ながら、携帯電話は一般的にインターネットに接続された状態で過ごすことはほとんどないため、利用可能な真のプッシュ メカニズムはPushRegistryAPI を介した SMS/MMS のみです。トゥルー プッシュの本当の問題は、サーバーがクライアントを識別する方法を必要とし、モバイル ネットワーク オペレーターによって携帯電話に与えられた一時的な IP アドレスに頼ることができないことです。

HTTP 接続チャネルの使用を計画している場合は、サーバーをポーリングしてチャット メッセージの更新を確認する必要があります。ただし、この悪い状況を軽減する方法があります。

ゲームがサーバーとの間で定期的にデータを送受信する必要がある場合は、チャット データを http 要求と応答の本文に独自のプロトコルにまとめることができます。

SMS プッシュを使用して HTTP によるデータ取得をトリガーすることで、技術的には 2 つのアプローチを組み合わせることができますが、コストが高くなる可能性があります。

MIDlet Java コードでのキーワードの適切な使用についてsynchronizedは、別の問題領域であるため、含まれているコード サンプルを使用して、より正確な質問をすることをお勧めします。

Answer 2

ポーリングする必要はほとんどありません。ほとんどの場合、ポーリングはリソースの無駄遣いです。あなたが提案している設計では、ポーリングスレッドがトリガーされるたびにコンテキストスイッチが発生し、リクエストを処理する必要があるかどうかを確認するために数サイクルかかります。ネットワーク コードにポーリングを追加すると、深刻な遅延が発生します。

直面している問題は、Observer パターンを使用して簡単に解決できます。(ここでは、patterndepot.org からのこのパターンの pdf の説明を示します。ここでは、JavaWorld.com の説明を示します) さらに、マルチスレッド環境で作業する場合、ポーリングには、コンテキストの切り替えと同期という欠点があり、その後、メッセージ バスのチェックにそれらのリソースを費やす必要はありませんでした。java.util.concurrentパッケージの並行コレクションを使用してメッセージを保存することを検討してください。

最後に、あなたの一般的なアーキテクチャは、サーバー側でいくらか作り直す必要があるように思えます。ユーザー負荷を高くすることを計画している場合、各ユーザーに新しい中間層処理スレッドを導入すると、最終的にはサーバーのパフォーマンスが低下します。これは、コンテキストの切り替えが多くなり、タスクがより強力になるためです。