野生のエンジニアたちが、サーバ跨ぎのPT募集実装に向けてアレコレ議論するスレッド

[AerialLuster]

略

すみませんｗ
読んでいる途中でサーバー間というフレーズの方に意識しすぎて"DC内の"という文言がきれいさっぱり忘れ去れていました。。。。

ただ、速度という観点からは欧州DCから日本DCや北米DCに接続されている方やその逆の方、中間地点に居住されている方もいることから、現状がそのような方はDC同士のやり取りが無くなれば速度的にはそれほど問題ではないのかなと思います
ラグは気にせず異なるDCの方と遊びたいという方もいらっしゃるでしょうしね

[noton-noton]

Iruru さんご意見ありがとうございます。
キーワードを使ってのCFマッチングというのは、フォーラム内のどこかにも提唱されていましたね。
マッチングのみだけなら、それで可能だと思います。

問題は、その先のコンテンツの共有部分でございます。　一つ上のコメントを参照ください。

＞AerialLuster　さんへ
北米DCのユーザーが接続されているAPサーバーからみて、参照するあらゆるデーターは同DC内に高速でアクセスできる環境にあります。

遠方になるコンテンツサーバーへの接続？　VPNかな？を利用した接続となると、直接遠方のDCに接続した状態に比べて、似て異なる状況が考えられます。
VPNの通信使用料はだれが負担するの？（高速・かつ大容量のVPN接続はお金がかかります）
ttps://flets.com/vpnwide/s_fee_ew.html　フレッツの広域VPNサービス
などちょっと難しい面があります。

それぐらいなら、ロビーサーバーから接続先を変えるように、直接遠方DCへつなげればいいのですが、
今度はキャラクターのデーターを、別途転送する必要が考えられます…
コンテンツ参加に必要なデーターだけなので、まだこちらのほうが目があるかもしれませんね

[AerialLuster]

＞AerialLuster　さんへ
北米DCのユーザーが接続されているAPサーバーからみて、参照するあらゆるデーターは同DC内に高速でアクセスできる環境にあります。

遠方になるコンテンツサーバーへの接続？　VPNかな？を利用した接続となると、直接遠方のDCに接続した状態に比べて、似て異なる状況が考えられます。
VPNの通信使用料はだれが負担するの？（高速・かつ大容量のVPN接続はお金がかかります）
ttps://flets.com/vpnwide/s_fee_ew.html　フレッツの広域VPNサービス
などちょっと難しい面があります。

それぐらいなら、ロビーサーバーから接続先を変えるように、直接遠方DCへつなげればいいのですが、
今度はキャラクターのデーターを、別途転送する必要が考えられます…
コンテンツ参加に必要なデーターだけなので、まだこちらのほうが目があるかもしれませんね

私の話は、その前の投稿の仮想DCでゲームデータを仮想DC内のDBにコピーして、DC間の通信がなくなった状態での話です
この構成でDCを跨いだマッチングでクライアントの接続先を仮想DC側に切り替えれば、通常ログインでDCを選択した状態と同様の状況になることを想定しています

クライアントでDCを選択してログインできるわけですから、VPNとか接続方式の話は一切関係ないと思いますが。。。。？

[noton-noton]

私の話は、その前の投稿の仮想DCでゲームデータを仮想DC内のDBにコピーして、DC間の通信がなくなった状態での話です
この構成でDCを跨いだマッチングでクライアントの接続先を仮想DC側に切り替えれば、通常ログインでDCを選択した状態と同様の状況になることを想定しています

クライアントでDCを選択してログインできるわけですから、VPNとか接続方式の話は一切関係ないと思いますが。。。。？

成程、事前にコピーしておくという事ですね。
（どうやってコピーするか？　という問題はありますが）

そうすると後は、CFが終わった後のつなぎ直し処理
褒賞や消耗品の利用業況アップデート処理　となりますね。


このアイデアの問題点は、DCセンターをもう一つまではいかないまでも
APサーバー
キャッシュ　
コンテンツ
と用意しなければならず、まさに吉田氏の指摘するところの、コストがかかるのが問題・・・・　でしょうか？

[AerialLuster]

ご飯食べながらちょっと考えてみました

チャットをするだけなら、チャットを仲介するためのプロキシサーバーを追加し、
プロキシサーバーは仮想クライアントとしてPTに参加したら各PTメンバーの所属ワールドにチャット仲介用のキャラクターを作成し、
PTメンバーがチャットを送信したら、チャット仲介用のキャラクターを通じて各メンバーにメッセージを送信する

つまり、
・ワールドを跨ぐPTに参加
・チャット仲介用のキャラクターをワールド毎に作成（チャット仲介用のキャラクターはキャラクタ名を、ワールド名-キャラクター名などで表示するなど、チャットタイプにより表示を切り替える）
・チャット仲介用のキャラクターに送信したチャットが、相手先ワールドのチャット仲介用のキャラクターを介してチャットを送信したい相手にやり取りされる
とすればなんとなく行けそうな気がします

[AerialLuster]

成程、事前にコピーしておくという事ですね。
（どうやってコピーするか？　という問題はありますが）

そうすると後は、CFが終わった後のつなぎ直し処理
褒賞や消耗品の利用業況アップデート処理　となりますね。


このアイデアの問題点は、DCセンターをもう一つまではいかないまでも
APサーバー
キャッシュ　
コンテンツ
と用意しなければならず、まさに吉田氏の指摘するところの、コストがかかるのが問題・・・・　でしょうか？

コストに関しても、現状の構成をそのまま利用できる可能性があります
IDに突入する直前にIDを実行しているコンテンツサーバーを持つDCのDBサーバーにキャラクターデータをコピーすることさえできれば、
あとはセッション情報をDC間で共有して、クライアントの接続先をうまく切り替えることさえできれば、
見かけ上異なるDCにキャラクター移転サービスで移転したうえで実行されることと同意の状態で実行できるのではないでしょうか？

キャッシュデータについてはどのような情報がキャッシュされているのかはわかりませんが、
ID突入によるエリアチェンジで保持される情報がイニシャルされる可能性があれば最低限のデータ移動で済みそうです

[Seev]

（略）

ありがとうございます。
＞２．PTマッチングシステム
そうですね。JobフィルタやILフィルタのロジックそのものは既にあるものですので#53方式なら実装自体に大きな問題は無いかなと思っています。
私の案では簡易なID的機能（中でチャット等）まで考えているので、サーバも複数台持たないといけないかなと思い分散サーバ化しています。
募集掲示サーバの目的は、どちらかと言えばこの分散化したサーバから各種募集を同期し掲示するキャッシュサーバとしての動きですかね。
（マッチングサーバは加入依頼やエリア管理に集中させ、アクセスが頻発する掲示板参照は掲示サーバーに代行させる）

募集をひとまとめにすることが重要だと思うのでSANや共有メモリなどのストレージに情報をまとめておき、それを参照する動作がそれほどボトルネックにならないなら各マッチングサーバーが裏にある募集を参照して応答してもいいかなと思います。
（「何があるか」は各サーバーが答え、「これに入りたい」となれば実際にそのPTが存在するサーバへ案内する動作）

簡易IDのエリアまで用意するのがスペック上のハードルにはなっていると思うので、ここはあくまでサーバ跨ぎ募集の「参加状況」だけを管理し、CF側への申請を代行する機能だけで良いかもしれません
（この場合、集まっている途中のPTチャット等は難しい）

＞３．CF募集掲示システム
いえ、実際に「このCFがどれだけ人気があるか」を表示させてしまうと、懸念の通り余計に人気は人気、過疎は過疎が進行してしまうと思うので、あくまで「呼びかけ」を掲示するだけですね。
以前、ウルヴズジェイルを活性化させるためフォーラムに「○○時に合わせてCF申請しようぜ」みたいに呼びかけてた方がいらっしゃったんですよ。なかなか成果は出なかったようですが……

みんながまばらに「CF……諦め」→「CF……諦め」とするより、時間を合わせて一斉に「「CF!」」とやる方がマッチング確率が上がると思うので、そういった用途ですね。

[Seev]

募集掲示板を閲覧する方法：～

DC内全サーバから全掲示を捜査する作業が大きなネックになると思うので、これをいかに簡略化出来るかという部分は大事ですよね。

noton-notonさんの案は、
「そもそもサーバ間募集を行うコンテンツを制限する」ことが一つ。
「閲覧するための条件を設ける事で、一度に閲覧される数・頻度を減らす」事が一つですかね。

前者はともかく、後者で気になる点はデータの捜査回数でしょうか。
毎回全サーバに問い合わせを投げるとなると、細かな条件を設ける事で「検索した結果」のデータ量は減らすことができますが、各サーバがその「検索条件に該当する募集があるか」を、毎回チェックする必要がありますよね。
個人的には一度の転送量が100byteから1000byteに変わってもさほど影響無いと思いますが、１回が１０回になるとそれにかかるオーバーヘッドが馬鹿にならないかと思っています。

InfiniBand等の高速なIFを使うことでイーサネットに比べたらはるかに低レイテンシ高信頼性を確保することは出来ると思いますが、それでも毎回プロトコルのヘッダ解析やCRCチェックは発生しますよね。
　(Request)→(データ検査)→★閲覧条件のキー捜査→(データ作成)→(Responce)
目的の募集があるかどうか自体が捜査してみなければわからないため、実際に該当するものが無くても捜査及び回答（無かったという回答）は行う必要があります。
このやり取りが閲覧の度に全募集サーバに行われる事になるため、この辺りの負荷が厳しいのではと気になっています。

（略）

すいません。DCというキーワードが良くなかったですね。
私の案ではGaiaやManaなどグループを指してDCと呼んでしまっていました。
現状のCFがどのような通信経路で行われているか不明なため確かな事は言えませんが、別DCに繋ぎ変える際に遅延による強制切断や急激なラグの増加が考えられるため少し難しいかなと思っています。
グループ分けは元々開発としても不本意ながら分けざるをえなかったのだと思いますので、これを超えてまでの募集は除外して考えていました

[noton-noton]

Seevさんへ
通信料を減らす施策として、募集を閲覧するのではなく。参加希望者のリストをPT側から選ぶという方法は如何でしょうか？
まず、PTは「募集中に状況が変わる」為に、参照するたびに最新の情報が必要になりますが、参加者（個人）のほうは、登録後はデータに変化がありませんから
キャッシュに載せる事が出来ます。

用心棒を希望する＞モグパブに入店　という流れで考えてみました。

一人で入った時は、用心棒として登録
PTで入った時は要信望を探す（スカウトする）立場になります。

以下フロー図です。


※モグの店のようなエリアは、演出の為の小道具ですから、呼び出し機能だけでも実装は可能だと思います。

追加が必要にある機器は、用心棒リストの為のキャッシュでしょうか？


色々ご意見お待ちしています＞ALL

[aqua_steve]

別にええねんけど
サーバーとかの話してるんだからサーバー名に使われている用心棒という名称は使わないほうが良いのではないかな?
と用心棒で遊んでる1プレイヤーとして書いておくでござる