2012-02-21 10 views
0

私はチャットクライアントをバイナリソケットを使ってフラッシュし、C/linuxのサーバをソケットとlibevを使っています。私はメッセージを送受信するために適切な作業をしていますが、今はもっと複雑なステップを踏んでいます。チャットサーバのグループを管理するためのデータ構造

私のチャットサーバーでは、ユーザーを15人のグループにグループ化します。サーバーはユーザーごとに一意のIDを持つ必要があり、ユーザーが他のユーザーにメッセージをブロードキャストするグループをすばやく特定できる必要があります。ユーザー。私は、サーバがソケット接続ごとにファイル記述子を使用できると思っています。

問題は次のとおりです。特定のファイル記述子に対してlibevからreadイベントが発生します。このFDが属するグループをすばやく決定し、グループ内の全員にメッセージをブロードキャストする必要があります。 この問題の最適なデータ構造は何ですか?

答えて

1

ハッシュテーブル。 各ユーザーに関連付けられたgroupIDがあるようにし、hashTableはgroupIDをキーとして使用し、UserIDの配列を値として使用します。

+0

これは良い解決策のようです。 libevを使用している場合、私はパラメータが読み込みイベントに渡されることを制御しているとは思わない。 ev_io構造体は私が使用しなければならないすべてのものであり、FDのためのintを持ちます。私はあなたが何かにいると思う、私はこれを回避する方法を考えようとしている。 –

+0

私が考えることができるのは、FD上で一度ハッシュしてgroupIDを見つけ出し、次にgroupIDでハッシュしてuserIDの配列を見つけることだけです。 2つのハッシュテーブルと2つのハッシュの計算は、しかし、キラーかもしれません。 –

+0

2つのハッシュテーブルルックアップがパフォーマンスを許容できないものにすると思われる場合は、ネットワークソケットを介してI/Oを実行するときに、セットアップに深刻な不具合があります。同時に何人のユーザーがこれを対象にしていますか?数十万人? – unwind

関連する問題