ボイスチャットシステム

Multisoft-labのホーム    ご意見・ご感想等

ボイスチャットサーバー

全体的な構成

 ボイスチャットサーバーは図1のように、チャット機能を統括する部分(Master)と、 通信の管理やプロトコル解析などを行う部分(Entry, Session)に分割して構成されています。

ボイスチャットサーバーの構成

(図1)ボイスチャットサーバーの構成

 これらの各部分は、内部に1つ以上のスレッドを保持しています。 したがって、これらの間で情報を通わせるには、スレッド間通信を行う必要があります。 ボイスチャットサーバーでは、スレッド間通信にはメッセージ方式を採用しました。 SessionからMasterへ、そしてMasterからSessionへの情報伝達は主にメッセージによって行われます。 ただしこれら各部分の制御は、必ずしもメッセージで行われるわけではなく、関数呼び出しでなされることもあります。


各部の説明

接続要求の受付(Entry)

 Entryはクライアントから接続要求があったときに、ソケットを生成し、TCP接続を確立する部分です。 生成されたソケットはまだ動作していない空きSessionに受け渡され、そのSessionの動作を開始させます。

 以上がEntryの動作です。

チャット機能の中枢(Master)

 Masterはチャット機能の根幹部分を遂行します。主な機能を挙げると、Masterは

  • クライアントのログイン/ログアウト
  • 参加者リストの作成
  • メッセージの投稿受付/配布
  • 音声のコントロール
  • 音声メッセージの受付/合成/配布
を担います。

 Masterは各Sessionからメッセージで要求を受けます。 すると、その要求に応じて上記に示した処理を行って応答します。 応答メッセージには、メッセージの送信元に送る返答メッセージと、 参加者全員に送る放送メッセージとがあります。 表1にすべての処理要求メッセージとそれらの応答メッセージを示します。 要求メッセージとそれに応じた処理は、上で示したいずれかの機能に対応しています。

(表1)メッセージの種類と解説

要求メッセージ 返答メッセージ 放送メッセージ
M_LOGIN
意味:ログインを要求
付随情報:参加名
M_LOGIN_SUCCEEDED
意味:ログイン成功
付随情報:参加ID
M_LOGIN_FAILED
意味:ログイン失敗
付随情報:なし
M_MEMBER_LOGIN
意味:ログインしたメンバーがいる
付随情報:参加ID, 参加名
M_LOGOUT
意味:ログアウトを要求
付随情報:参加ID, 参加名
M_LOGOUT_SUCCEEDED
意味:ログアウト成功
付随情報:なし
M_MEMBER_LOGOUT
意味:ログアウトしたメンバーがいる
付随情報:参加ID, 参加名
M_GET_MEMBER_LIST
意味:参加者リストの要求
付随情報:なし
M_MEMBER_LIST
意味:参加者リスト
付属情報:参加人数, 参加ID, 参加名

M_MESSAGE
意味:メッセージの投稿
付随情報:参加ID, 参加名, 投稿メッセージ

M_MESSAGE
意味:メッセージの投稿を通知
付属情報:参加ID, 参加名, 投稿メッセージ
M_VOICE_START
意味:音声メッセージ投稿の開始
付随情報:参加ID, 参加名


M_VOICE_START
意味:音声メッセージ投稿の停止
付随情報:参加ID, 参加名


M_VOICE_DATA
意味:音声メッセージ投稿データ
付随情報:参加ID, 参加名, 音声データ

M_VOICE_DATA
意味:音声メッセージ投稿データ
付随情報:音声データ


通信の管理とプロトコル解析(Session)

 Sessionの構造を図2に示します。 Sessionはクライアントとの通信をサポートし、 クライアントの要求をMasterに伝えるとともに、 Masterから送られてきた情報をクライアントへ送信する作業を行います。 Sessionは2つのスレッドから構成されていて、 一方はソケットを通してクライアントからの情報を取り込むSession_receive_thread、 もう一方はクライアントへ情報を送信するSession_send_threadとなっています。 以下では、これら二つのスレッドの役割を説明します。

Sessionの構造

(図2)Sessionの構造

 まず、Session_receive_threadはソケットを監視し、クライアントから情報が送られてくると、 プロトコルにしたがってその解析を行います。 次に、解析が成功すると、それに応じたメッセージを作成して、 Masterのメッセージバッファへ投函し、以降の処理はMasterにゆだねます。 そして、Session_receive_threadは再びソケットを監視します。

 Session_send_threadは自分に割り当てられたメッセージバッファを監視し、 Masterがそこにメッセージを投函したら動作を開始します。 まずMasterが投函したメッセージを解析し、次にプロトコルにしたがってクライアントへの送信データを作成します。 そして、ソケットを通じてそのデータを送信し、再びメッセージバッファの監視に入ります。

 以上がSessionの動作概要です。 つまりSessionの役割は、(Masterとのインタフェースを通信と見なせば) インターネット側のプロトコルとMasterとの通信プロトコルを相互に変換するものです。 このようにチャット機能とインターネットとの間にSessionを介在させることで、Masterはチャット機能の中枢部分にだけ集中すればよく、 ソケットの管理などはしなくて済むようになっています。



音声合成の仕組み

 クライアントから送られてきた音声データは、Masterによって他の音声と合成され、ブロードキャストされます。 ここでは、音声合成のメカニズムを解説します。

 クライアントからの音声データの投稿(発言)は次のステップを踏まなくてはなりません。

  • 音声投稿開始信号
  • 音声データ
  • 音声投稿終了信号
 クライアントはまず、音声データを送信する前に、音声投稿開始の合図を送ります。 音声データはその次です。 そして、音声の投稿を終了するときは、音声投稿終了信号を送ります。

 図3に音声の合成を行う機構(VoiceMixCtrl)を示します。 まず、音声投稿開始信号を受信すると、VoiceMixCtrlは音声データのバッファを生成します。 そして、音声データが到着すると、このバッファに音声データを貯えていきます。 もし、すべてのバッファに音声データがあれば、合成して取出すことができます。 また、音声終了信号を受信すると、それに対応するバッファを消去します。

音声合成の機構

(図3)音声合成の機構(VoiceMixCtrl)

 この方法で音声合成を行うと、音声データの到着に少々ばらつきがあっても、その影響を吸収することができます。



実装

 表2にボイスチャットサーバーのクラス構成を示します。

(表2)ボイスチャットサーバーのクラス構成

クラス 内 容
CVoiceChatServerCore
 サーバーアプリケーションのコアです
CSession
 セッションの機能を統括します
CForClientDataBuffer

 MasterからSessionへ送られるメッセージのバッファです

 CThreadCommunicationBuffer<class T>のTをCForClientDataに置換えました。 詳しくはスレッド間通信の原理・構成をご覧ください。

CForClientData
 MasterからSessionへ送られるメッセージです
CToHostDataBuffer

 SessionからMasterへ送られるメッセージのバッファです

 CThreadCommunicationBuffer<class T>のTをCToHostDataに置換えました。 詳しくはスレッド間通信の原理・構成をご覧ください。

CToHostData
 SessionからMasterへ送られるメッセージです
CSock
 ソケット通信をサポートするクラスです
CVoiceMixCtrl
 各クライアントから送られてきた音声データの管理と合成を行うクラスです
CVoiceBuffer

 音声データのバッファです

 CQueue<class T>のTを構造体VOICE_FRAMEに置換えました。 この構造体は、音声の単位ブロックを保持するものです。




Multisoft-labのホーム    ご意見・ご感想等の受付


Copyright © 2004 Multisoft-lab   All rights reserved.