2011-12-22 9 views
4

私はCで複雑なサーバ - クライアントシステムを開発していましたが、ソケット通信の実装方法はわかりません。任意の双方向UNIXソケット通信

簡単に言えば、システムはデータベースと通信し、UNIXソケットを使用してfork()で作成された1つ以上の子プロセスと通信するサーバーアプリケーションです。子供の目的はゲームサーバーを稼働させることです。ゲームサーバーを起動するプロセスは次のようになります。

  1. サーバー/マネージャは、作成するデータベース内のゲームサーバーを識別します。
  2. マネージャは、子供(「ゲームコントローラ」)をフォークします。
  3. ゲームコントローラは、2つのパイプペアを設定し、その後フォークを設定し、その子の標準入力をパイプで置き換え、stdoutとstderrを別のパイプで置き換えます。
  4. ゲームコントローラの子供はexeclp()を実行して、実際のゲームサーバーの実行ファイルの実行を開始します。

私のソケットに関する経験は、ごくわずかです。 GNU Cのドキュメントhereの簡単な例に示すように、多くのクライアントを「多重化」する前に、サーバアプリケーションでselect()を使用しました。

私は今、新たな課題を抱えています。マネージャは、ゲームコントローラの子どもたちに任意にコマンドを送信する必要があります(データベースを定期的にチェックすることで見つけることができます)。しかし、でもはそれらからの任意のコマンド/エラーを受け取り、返信を返すことを期待しています。

だから、私はソートがコンテキスト間でのみ意味のある「コンテキスト」システムが必要です。言い換えれば、コマンドがマネージャからゲームコントローラに送信されるとき、各当事者は、誰が尋ねているのかを知る必要があり、返信が何であるかを知る必要があります。

select()は、受信データがあるときを知っていてスレッドがそれをブロックする必要があるため、データを送信して応答を受け取る別のスレッドが必要ですか?これは、技術的には「クライアント」であるけれども、各ゲームコントローラはリスニングソケットを使用し、select()も使用する必要がありますか?

システムと問題を簡潔に説明していただきたいと思います。必要に応じて詳細を追加します。ありがとう!

+0

私はそのほとんどを理解していると思いますが、「ソケットは自分の間だけで意味があります」という意味を説明できますか? – frankc

+0

ソケットを介して送信されたコマンドは、あなたが 'accept()'のように応答し、反対方向に流れるソケットを受け取るでしょうか?あるいは、基礎となる外挿プロセスをより効率的に実装する方法があります。 – Doddy

+0

データを受信して​​いるソケットを知っているため、「各パーティは誰に尋ねているのか分からないでしょうか? –

答えて

1

私はあなたの問題がどこにあるのか正確にはわからないので、クライアント/サーバーアプリケーションの作成についていくつかのことを説明します。私がオフトラックの場合、私に知らせてください。

  1. サーバがどのソケットに対応するかをクライアントが知る方法は、クライアントがサーバに伝えることです。基本的には、ログインプロトコルが必要です。ゲームコントローラがサーバーに接続すると、「こんにちは、私はホストxyz、ポートabcにコントローラfoo1として登録しています...」というメッセージと、サーバーがそのクライアントについて知る必要があるものを送信します。サーバーは、ソケットをクライアントのメタデータ、状態などにマップするデータ構造を保持します。新しいメッセージを取得するたびに、着信ホスト/ポートからメタデータに簡単にマッピングできます。または、あなたのプロトコルは、各着信メッセージに対して、クライアントがフィールドとして登録した名前を送信することを要求することができます。

  2. 要求/応答の処理はいくつかの方法で行うことができます。まず、サーバー側のネットワーキング部分を扱うことができます。これを管理する1つの方法は、前述したようにselect(またはpollまたはepoll)を使用してソケットを多重化することです。これは、実際には、通常、より複雑な方法で行われます。もう1つの方法は、受信クライアントごとにスレッドを生成する(または、あまり一般的ではないプロセスをforkする)ことです。各生成されたスレッドは、自分自身が割り当てられたソケットを読み取ることができます。メッセージは、自分自身以外のクライアントが存在することを気にせずに応答します。この単純な1対1のスレッドからソケットへのモデルは、多くのクライアントが存在する場合には分解されますが、そうでない場合は考慮する必要があります。

第2部では、実際にはサーバーにメッセージを送信するクライアントとサーバーからの応答のみを扱います。サーバーが通信を開始したいときはどうなりますか?それはどのようにして、クライアントはそれをどのように処理しますか?また、アプリケーションレベルでのコミュニケーションモデルをモデル化するにはどうすればいいですか?つまり、読み込み/書き込みの部分があると仮定すると、送信する内容をどのように知ることができますか?あなたはおそらく状態機械の点で事物をモデル化したいと思うでしょう。クライアントがクラッシュしたときにどうなるかのように対処するにはさらに多くのことがありますか?サーバーがクラッシュするとどうなりますか?また、あなたが実際にselectを使ってあなたの心臓を持っていれば、おそらくあなたは多くのクライアントを期待しているでしょうか?私は明日この答えにもっと加えようとします。

関連する問題