AVP2 Top
AVP2サーバ、OTSUKARESAMA(JP)を紹介をするコーナーです。
■ OTSUKARESAMA(JP) Server公開
2002年5月からAVP2サーバをUPし始めましたが、その時からOTSUKARESAMA（JP）という名前でした。
当時はまだサーバ機を所有していなかったので、Celeron850MHZ,Memory384MBのPCで運用していました。
現在はDual CPU仕様のPCサーバに変更して不定期で運用中です。
2006年10月からPentiumⅣ 2.4CGHz(Hyper Threading)で不定期でDOOM3サーバーと同時に再開しました。
LinuxはFedoraCoreはちょっと重いので定評がある｢Vine Linux｣に変更しました。
■ 採用MAPについて
OTSUKARESAMA(JP)]でもBugCenterと同じく標準マップを使用しています。
■ サーバPORT
以下のPORT番号を設定。
メインサーバ 27888 (AVP2デフォルト値)
■ サーバーの対戦モード
Team DeathmatchやEVACなどでUPしています。細かい設定は時々見直しますが
Life Cycle、Frinedly Fire DamageはOFF、Class Weapons Setは常にOFFにしています。
tamachiの趣味で人間種族はMarineだけに設定しています。
■ Linux版AVP2サーバ
Linuxで運用していることが、このサーバの最大の特徴です。
プログラムはavp2linuxというモジュール名でAVP2発売元のSierraから提供されています。
ファーストリリース時はVer1.95でしたが、現在はWindows版と同じ1.96になっています。
残念ながらトラブルがあってもメーカのサポート外で自力で解決するしかありません(TT;
■ サーバコンソール
下の画面はAVP2サーバ起動中のコンソール画面です。
コンソールといってもGUIでなく、キャラクターベースのためログが表示されるだけで
サーバを起動、終了する以外はコンソールから操作できません。
Boot（Kick）やレベルの移動がコンソールからできないので、Joinしてコマンドでサーバをコントロールでします。
このためLinuxで運用する場合はサーバコマンドの習得はmustです。（習得というほど大げさではないですが）
プログラムの起動方法はLinuxらしく、ターミナルプロンプトからコマンドを入力して起動します。
ブランクの後に設定ファイル名を指定します。
たとえばファイル名がteamdm.txtの場合
コマンド例：.avp2linux teamdm.txt
詳細はreadme.txtを見てください。
"REDHAT7.3 AVP2 Server Console"
LINUX版のAVP2サーバーは元々このバーっジョンをサポートしている。
"FedoraCore3 AVP2 Server Console"
2005年2月現在、最新のこのOSでもレガシーアプリケーション対応機能で問題なく稼動する。
■ Linuxリソースモニタ で監視
下の画像はAVP2サーバの稼動状況をモニタするためいつも起動しているLinuxのリソースモニタです。
（Windowsのタスクマネージャーと同一機能と思ってください）
タスク（スレッド）状況、サーバのメモリ使用量、CPU負荷率、起動時間などがリアルタイムにモニタできます。
"REDHAT7.3 "
"FedoraCore3"
囲み部分がAVP2サーバのプロセスとスレッドの稼動情報です。同時に6個バックグラウンドで動いています。
"CPU負荷"
標準MAPの使用で,、Windows版のAVP2サーバとの比較ではCPU負荷が高くなる傾向になります。
これはLinux版のAVP2サーバのCPUの使い方がWindowsより効率が良いためと考えています。
OTSUKARESAMA(JP)はCPU2個のサーバで動いているので
下の画面には対応して2個表示されています。この画像は10人以内のプレーヤーJOIN時のもの。
下はサーバーがレベルチェンジ後の画面。レベル変更は大変重い処理ですが片方のCPUで処理して
おそらく通信などの他の動作に必要な処理は別のCPUで行っていると想像できます。
右側のピークがレベル変更実行時のもので瞬間的に100%CPUを使用しています。
■ Linux版サーバとマルチスレッド
上のモニターをみるとわかりますが、Linux版ではサーバプログラムのavp2linuxが
同時に6個動いています。このため以下のメリットがあります。
1.サーバとプレーヤ間のレスポンス
ネットワークを経由した通信ではマルチで非同期にPCと通信ができるので
プレーヤ数が多い環境でもレスポンスが低下しにくい。
2.プレー中に移動すると
移動がスムースになったのがJoinして移動するとすぐに体感できます。
3.LAG問題
これは何ともいえませんね。こちらの環境以外にも参加するプレーヤ側のネットワークや
PCのハードスペックなどの問題もありますので．．．
でもPingが高いプレーヤがいる場合、Windows版のサーバだと全体に影響がでてLaggyな状態に
なったりしますが、Linux版のサーバですとLaggyなプレーヤはそのままですが他のプレーヤにまで
影響は及ぼさないようです。
これもマルチスレッドでプレーヤとの通信を制御してる効果がでているのかもしれません。
■ Linux版サーバ各スレッドの役割
これはあくまでtamachiの想像ですがavp2linuxは6個のスレッドが内部で連携して同時に
以下のようなことをしているかもしれません。
tamachiがAVP2サーバをデザインするとしたら以下のようにたぶん考えるかもｗ
①管理/監視用スレッド
１個はSierraのマスターサーバとj通信を定期的にして ユーザーの接続状況、ゲームモード
各種パラメータ、Frag、Levelなどのサーバの状況や設定値を通知したり他のサーバの情報を
マスターサーバから受け取っているようです。
通信アナライザーでみると他のサーバの情報も受信していましたがなぜそんなことするのか不思議です？
あとサーバ名はもちろんサーバに接続中のプレーヤー名、Race（種族）/Frag数なども送信しています。
これらの情報は下の②制御スレッドから受け取ります。
②制御スレッド
もう１個のスレッドはPCのJoinを監視していてそのセッションにIDを割り当てて内部で管理しています。
このためサーバでLevelが変更になっても常に接続が維持されるのです。
MAX16プレーヤー分の情報を常に管理できます。
管理している情報は
接続中のプレーヤー名、Race（種族）、種別のタイプ（HarrisonとかDroneとか）、Frag数など
プレー中にtabキーを押すと表示される情報です。
この情報は上の①のスレッドに情報を送っています。
このことをスレッド間通信とかIPCとかいいます。
情報の送信はメモリを使用しています。（これを共有メモリーとか呼んでいます）
あとこのスレッドは下の③通信スレッドに接続したプレーヤとの通信をのこりの４個のスレッドの
どれにまかせるか現在のプレーヤー数をチェックして決定して通信スレッドからプレーヤの情報を
受け取ります。 このスレッド自体はPC（プレーヤ）との通信は行いません。
③通信スレッド
のこりの４個のスレッドは上記②制御スレッドが割り当てたプレーヤとの通信を専門に実行します。
制御スレッドからセッションIDを受け取り１個につき４プレーヤーを受け持ちますが4プレーヤ以上でも
通信はできるようです。（Windows版は少なくともそうでした）
以上ちょっと面倒な話でした。一部確認した部分は除いてあくまでtamachiの想像です。
個人的にはLiztechのディベロッパーに直接話を聞いてみたいものですｗ
■ 紅白戦サーバ（第5回大会）
久しぶりにメインサーバのLinuxで公式戦サーバを運用しました。
atuageさん主催の『KOUHAKU 5 OTOKO[JAPAN]』大会でのUPで今回はCMP4を採用するということで
例によってCMP4をサーバに設定し、テストサーバをUPしました。
Linuxサーバの場合、カスタムMAPは使用できるものの、REZファイルでないと動作しないという制約があります。
そのため以前から勝手にCMP4一式をREZファイル化して運用していました。
CMP4自体はもともとdatで提供しているので動作がおかしくならないか不安でしたが
監修者のAcidGlowさんによるとREZ化しても問題ないとのことだったのでそのままWindows版でも利用しています。
CMP4のREZファイルは1.5GByteのサイズになりかなりでかくなります。
OSをFedoraCore2に変更してからはじめての公式戦でしたがトラブルはなかったようです。
真剣勝負の最中に途中から乱入して失礼しました！
今回も対戦結果が楽しみです！
【KOUHAKU 5 OTOKO[JAPAN]サーバ FC2のサーバコンソール】2004/08/28 初のFC2サーバでの公式戦。
PORT 対戦モード Linux Server コンソール Linux monitor Multi thread Threadの役割 紅白戦サーバ
