4

ネットワークに関するいくつかの Web ページを読んだ後、基本的なネットワークを理解しようとして (私は以前にネットワークを行ったことはありません)、単純なチャット ルームを作成するように設計されたいくつかのクラスを作成しました。以下のクラスが掲載されます。

ChatServer: http://paste.strictfp.com/32591 ((最近編集)人々が接続するのを待つ実際のサーバーの作成、この場合はポート 9045 経由)

ChatSession: http://paste.strictfp.com/32583 (クライアントが見つかると、上記のサーバー コードから新しいセッションが作成されます。これは基本的に、クライアントから送信されたメッセージを読み取るだけです)

ChatClient: http://paste.strictfp.com/32584 (クライアントがサーバーに書き込むことを許可します)

ServerRunner: http://paste.strictfp.com/32585 (サーバーを実行する主な方法)

ClientRunner: http://paste.strictfp.com/32586 (サーバーに接続するクライアントを実行するための主な方法)

ソケット/クライアントが切断されたかどうか、または何かが中断されたかどうかを確認するチェックを追加しなかったという事実を考えると、上記のコードが最適ではないことはわかっています。繰り返しになりますが、これはネットワーキングの概念を理解しようとするための練習に過ぎませんでした。

したがって、これらの 5 つのクラスは一緒に問題なく動作しますが、回答があれば非常にありがたい質問/懸念があります。

サーバーからクライアントにメッセージを送信するにはどうすればよいですか?

私が尋ねている理由は、サーバーと 2 つのクライアント (どちらもプレイヤーを表す) があるシンプルなマルチプレイヤー tic-tac-toe ゲームを作りたいからです。クライアントがボタンをクリックすると、サーバーにメッセージが送信されます。そして、両方のゲームを変更するために、両方のクライアントにメッセージを送り返します。また、ネットワークの知識が不足しているため、それがどのように機能するかについて少し混乱しています. 非常に単純な場合を除き、別の URL にリダイレクトしないでいただければ幸いです。誰かが私を助けることができれば、それは非常にありがたいです.

4

2 に答える 2

1

「サーバー」という言葉には、混乱を招く可能性のある 2 つの意味があります。

  1. サーバーは顧客にはないものです (つまり、すべての顧客/ユーザーが接続する中央ハブです)。
  2. サーバーはリクエストを受信するサーバーです。サーバーは会話を開始することはなく、常に着信メッセージに応答するだけです。

したがって、あなたがやろうとしているのは、サーバーをクライアントに変えることです (そして、それChatClientがサーバーになります)。

これは、この一見単純なタスクが非常に難しい理由を説明しています。サーバーは、突然クライアントと通信することを意図したものではありません。現実世界の例: 銀行の店員が突然玄関先に現れ、自宅で何かを売ろうとしました。奇妙ですね。

ソリューション:

  1. クライアントから数分ごとにサーバーにメッセージを送信させることができます。メッセージは「何か新しいものはありますか？」です。これを「ポーリング」と呼びます。
  2. クライアントにメッセージを送信させ、応答を待つことができます。サーバーがメッセージにすぐに返信する必要はありません。ただし、処理する必要があるタイムアウトがあります。しかし、クライアントは「何か新しいものはありますか?」というメッセージを送ることができます。そして返事が来るまで待ちます。これをスレッドに移動すると、クライアントは応答を待っている間に別のことを行うことができます。これはポーリングですが、パッシブです。
  3. WebSocketなどの双方向プロトコルを使用できます。
  4. クライアントを実サーバーに変えることができます: サーバーソケットを開き、中央ハブにポート番号を知らせ、そこに接続してクライアントを更新します。これは機能しますが、2 つの接続が必要で、少し高価です。これは、クライアントの数が少ない場合はうまく機能しますが、数が増えると、最終的には問題になります。
于 2012-08-24T13:42:14.147 に答える
0

先に進む前に決定しなければならないことの 1 つは、プレーンな TCP ソケットの上にアプリケーション レベルのプロトコルを構築する方法です。これは、どちら側が会話を開始するか、どのような種類のメッセージをやり取りしたいかなどです。

次に、しばしば厄介なポイントは、メッセージ自体のレイアウトを決定することです。メッセージがテキストかバイナリか、および完全なメッセージを受信したかどうかを受信側がどのように認識するかです。ここでの通常の混乱は、TCP 接続がバイトの双方向ストリームを提供することを理解していないことであり、メッセージの開始位置と終了位置を把握する必要があります。ここでの従来のオプションは次のとおりです。

  • 区切りメッセージ - テキストベースのプロトコルに最適です。最も単純な形式は、改行が区切り文字である line-is-a-message 表記です。
  • 固定長メッセージ。バイナリに最適。
  • 長さの前に固定されたメッセージ - 続くバイト数を示す固定長のヘッダーがあります。
  • S 式、XML などの自己記述型メッセージ。通常はテキスト。

これが少し役立つことを願っています。

于 2012-08-24T13:49:21.683 に答える