VCEについてのよくある質問

VCEは、リアルタイムネットワーク機能が必要とされるアプリケーションに最適です。

MMORPG 等、大規模オンラインゲーム

大量のセッションを扱うサーバを、少ない依存関係と簡単な記述で実装できます。 クライアント側も 1 本または少数のセッションで無駄がなく、低コストで通信処理をすることができます。 また、 Monitor 等の機能と組み合わせると、BOT 等の不正行為への対策をあらかじめテストすることができるため、 運営時の管理の手間を抑えることができます。

大規模ロビーと小規模オンラインゲーム

カジュアルゲームに見られるようなプレイヤーが集まるロビーと、実際にゲームを始める際に必要なアプリケーション等の小規模サーバやクライアントを直感的に実装できます。 また 1 対 1 のゲームであれば、セッションの違いをほとんど意識することなく作ることができます。

高速単純なサービス

セッションが独立しているため、データベースのように、単純なリクエストに対してレスポンスを返すだけのサーバも、複雑な設計をせずに実装することができます。 HTTPServer の機能を使うと、汎用の HTTPd を使う場合と比べ、CGI プロセスの立ち上げやディスクアクセス等を極端に抑えることができるため、 高速なサービスを実現できます。また、独自プロトコルを実装して、スケーラブルな Web サーバを作ることもできます。

型に対しての安全性や利便性など、VCE1で採用していたC言語に比べてメリットが大きかったため、C++言語を採用しました。

マルチスレッド環境でも動作しますが、APIはスレッドセーフではありません。VCEは必ず 1 つのスレッド内に動作を納め、アプリケーション側で同期処理をおこなう必要があります。また、オンラインアプリケーションはコードが複雑になりデバッグしにくいため、マルチスレッドではなくマルチプロセスでの実装を推奨しています。

また、推奨される方法ではありませんが、異なるVCEインスタンスをそれぞれ独立したスレッドで利用することができます。この場合はアプリケーションの開始時にvce::VCEInitialize()を、終了時にvce::VCEFinalize()を呼び出す必要があります。これらはVCE内部で共有資源へのロックを初期化します。

はい、対応しています。ですが、ほとんどの場合TCPで充分対応できますし、実際にTCPで問題が生じたケースは今のところありません。

UDPはその仕様上、データが欠落したり順番が入れ替わったりしてしまいますが、VCE2はデータの再送や構築をサポートしているため、TCPと同じように信頼性のあるストリーム通信ができます。

UDPセッションは小さなデータを短い間隔で通信するのに向いています。

クライアントとサーバ間の通信はVCEにより暗号化が可能なので、データ送信中の改竄はないと考えられます。ですが、クライアントのメモリの書き換えは防ぐことができません。受け取ったデータが正しいかどうかはアプリケーション側で確認する必要があります。

完璧に防ぐことはできませんが、防止ルーチンは簡単に組み込むことができます。

既存のmallocルーチンでは、通信ライブラリとして要求されるメモリ管理が実現できなかったため、独自のルーチンを用意しました。具体的には、

• メモリを固定長で確保したい
• 高速にアクセスしたい
• 稼動が長時間となるサーバでのメモリフラグメンテーションを防ぎたい

などです。

VCE自体には限界はなく、マシンのCPU速度とメモリに依存しています。CPU速度1GHzで同接1000本が目安です。ただし、これは目安ですので、ゲーム処理でCPUの負荷が高ければ、同時接続数も減少します。

英語版ドキュメントは準備中です。もうしばらくお待ちください。

VCEと同等の安定性をもつ通信ライブラリを0から作るとすると、およそ100人月以上と思われます。

技術的には携帯電話への対応は可能と考えています。ニーズにあわせて柔軟に対応しますので、お気軽にご相談ください。

VCEではCamellia暗号アルゴリズム、Mersenne Twister擬似乱数生成アルゴリズム、およびzlib圧縮アルゴリズムを使用しています。

第三者の商標についてもあわせてご覧ください。

VCEは多くの製品でご利用いただいています。詳しくは採用実績のページをご覧ください。