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

Quote:

---

Originally Posted by aqua_steve

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

---

たぶん用心棒は正規な意味での使い方かと。

サーバー名じゃなく………。

MMO
サーバーとクライアントは何を通信しているか？

エモート：お辞儀をする　この時何が通信されるのでしょうか？　考察してみます。

「お辞儀」でどのくらいの通信量が発生するでしょうか？　キャラクター一つのデーターなので、結構なデーター量を送っています…
ということはありません。

送信されるのは、お辞儀を「誰に」した。というデーターのみ。　数バイトが送られるだけです。
お辞儀をするという命令を受け取ったAPサーバーは、共有空間のキューに「コマンドを」スタックします。
そして、そのエリアに存在する、他のプレイヤーに対して、お辞儀するという命令（キャラクター名＋対象のキャラクター名）を送信します。

お辞儀するという命令を受け取ったクライアントは、クライアント内の３D描画エンジンに「あらかじめ用意してあるお辞儀モーション」に従って
キャラクターを動かします。　それが、他のプレイヤーの映像として表示されます。

チャット部分には「キャラクター名」情報が付与され、「○○は▽へお辞儀した」と表示されます。

（※キャラクター名は別途まとめて処理している可能性もあります）

このように、１コマンドで数十バイト（キャラクター名２名の文字列とコマンドINDEX）２０文字程度送られます。

とはいっても、これが沢山になると、とても忙しい事になります
Sモブハントでは、大量の他人のコマンドを受信します。
カクカクになるのは、クライアント側の処理が間に合わない事で発生しています。

実はここでも、通信そのものには余裕があります。
一般に通信で最大の速度が出る「ファイルのダウンロード」ですが、その時の送信量と比較すると、秒あたりの転送量で考えると導き出せます。

20Mbps　＝　2.5MB/秒
1アクションで100byteで計算
2500000/100　＝ 25000
25000/60　（1/60秒あたり）416アクション


話を募集に戻すと…

募集のクライアント側表示に関して、Sモブハントより通信量が増えるといった事はないと思います。
∴この部分に対しての心配は無用です。

パスワードPW式が一番現実的な気がしなくもないのですが。
Notonさんは「共有部分が…」と言っていますが、意味がわかりません。

パーティチャットの部分なのですかね？
現行のIDでは、インスタンスエリアIAに入るまではチャットが有効にならない感じですが、それを超えて鯖横断でチャットができるように、となると、そもそも論として現状には無い、新しい仕組みが必要のように思えます。

PW式の場合、PTの条件、その他諸々については「チャットアプリ（仮）で既に解決済み」とすることができ、ゲーム内においては「PTを最終的に組むかどうか？」だけの判断で済むわけで、PTチャットも現行通り、IAに入ってから行う方式で問題なく（それ以前の問題はチャットAP（仮）で解決済みと見込む）、「PWでPTを作るかどうか？」の部分だけを新設すればいいように思います。

チャットAPに関しても、公式でサポートすると不適切な発言等を監視しなければならない手間もあるでしょうから、LINEでもロビでも既存のAPを利用できるようにし、公式では最低限「PWによるPT認証」の仕組みだけをサポートすればいいことになります。
そもそも鯖越えPT募集は、個々の鯖に縛られるモブハンやFATE、FC募集、CFやユーザーEV等では必要とされず、CF非対応のコンテンツに限れられるわけですから。

外部APでメンバー募集→条件その他で合意→

『募集主がPWを教える→そのPWを元に参加者が申請→合致していたらPT作成（ただしIAに突入するまではチャット不可。シャキ後のメンバー同意待ち状態）』
↑ここを新設。

→PTメンバーが全員揃ったらIAに突入→「よろおつ」

つづき


ゲーム内としては、PWが合致しているかどうか？　を判断すればよいと思います。
それでも極論では募集板にアクセスできる全てのプレイヤーが問い合わせをする可能性がある、と見込まざるを得ず、それを制限するためにパスワード認証は1分（3分？）のインターバルが必要ということで。
合意済みのはずの人がアクセスするだけですし、何らかの手違いがあったとしても（主の勘違い等？）、認証が1～3分間隔でも、実用上ほとんど影響は無いものと思います。

私自身は、
「なるべくコストをかけない実装」→「『零式を（既に実績のある）CF対応に！』と、どれだけ違うのか？」

痒いところに手が届くPT募集→「面倒くさい割に、事実上、零式PT募集くらいでしか使われないのに、そんなにコストをかける意味があるのか？」

というスタンスです。
その中間に鞍点があるのでしょうが、どうせ専門系のスレに移行したのなら、その辺まで考えてみましょう、と思います。

Quote:

---

Originally Posted by MisatoMisa

たぶん用心棒は正規な意味での使い方かと。

サーバー名じゃなく………。

---

?
だからややこしいから使わないほうがいいんじゃないかな?っていう話ですよ

Quote:

---

Originally Posted by aqua_steve

?
だからややこしいから使わないほうがいいんじゃないかな?っていう話ですよ

---

まぁお手伝いとかそういう例えだと良かったですね。

自分は用心棒と言えば時代劇連想ですが…………。

>Theel さんへ
＞共有部分
APサーバーは、負荷を減らすために複数台から構成されますが、ワールドサーバー（エリアサーバー）は、それらのAPサーバーから見て１つの情報を共有します。

チャットですが、おそらくこのワールド毎にメッセージキューを持っています。

例えば、リムサにアクセスしているユーザは、リムサメッセージキューからメッセージを受け取ります。
IDの場合は、IDにあるメッセージキューからチャットメッセージを受け取ります。

IDサーバーはグループ共通でアクセスできるようになっていと思われます。（CFやFLで他サーバーの方と同居できる）
メッセージキューはそこにあるため、異なるサーバー間でチャットが届くようになります。

IDと同じ仕組みで小さなエリアを作成。
PT予定者の位置情報を切り替えることで、PTのメンバーはメッセージをそのエリアのキューから受け取るような動きにできるでしょう。
他の仕組みと差異はありません。

尚、PTはPTでメッセージキューを持っていると思います。


＞私自身は、「なるべくコストをかけない実装」→「『零式を（既に実績のある）CF対応に！』と、どれだけ違うのか？」

私も同じような形を最小の拡張で済むような方法を、最初に提唱したのですが、いまひとつの反応だったので、もう少し色々と考えて方法を提案している所です。


＞用心棒
そこに指摘が及ぶとは思いませんでした。
ここでは仮の名称なのでご了承ください。

要件定義では認識の齟齬がないように言葉とかをしっかり確認するのは必要なことですね。


それはさておき、要件定義まだなのに、設計フェーズに移ってる気がしてモヤモヤするのは私だけでしょうか。

サーバー跨ぎの募集板に関連する
・チャットができる必要性はあるか
・（事前に）PT組む必要があるか
等々の検討がおいてけぼりになってるような。

F-DUCT　さんへ
ご意見ありがとうございます。

私は現在、２つの方法を提唱させてもらっていますので、CF拡張の方法の説明をします。

募集側　
・UIは募集板を拡張したものを利用する
・ローカルの募集と並行して募集ができる
・FULLパーティのみ利用できる

応募側
・CFに登録する時に、追加の条件をセットする

マッチング
・全員が揃ったら、即開始される。


メリット
・１～２名足りない時など、補充用途に使いやすい
・応募側もローカルで募集が無い時でも、呼ばれる可能性がある
・応募側は募集を待つ間の拘束が比較的軽い
・ハードウェアの追加もおそらく最小で済む

デメリット
・事前に打ち合わせができない（CFと同じ問題）
・プリセット以外の細かい条件を設定でいない。
・時期（混雑時）には利用できない場合もある（アクセス調整）

HarukaPhilanthaさんへ
ご意見ありががとうございます。

＞サーバー跨ぎの募集板に関連する
・チャットができる必要性はあるか
・（事前に）PT組む必要があるか

まずはDCセンターを跨ぐのか？
グループをまたぐのか？

レンジを決めることが必要でしょうね。
個人的見解ですが…

まずDCを跨いでの募集機能は、技術的な話は別にして不要だと思います。
折角、言語が違うプレイヤーを隔離しているのに、
エンドコンテンツという、コミュニケーションが必要な環境に於いて、PTが組めるメリットがない。と思います。

GPサーバーを超える接続は、現状物理的なネットワークも遮断されているのではないかと推測します。
（正しくはゲームに必要な高速回線での接続）

よって、レンジ（募集の範囲）はグループサーバー内のみ　と限定しても良いと思います。


事前のチャット、事前のPTについて

・完全に開始できる状況になってから、突入前に時間を区切ってPTを組む事は可能。というのを提案します。

理由は、少し前にコメントしましたが、「固定の遅刻のキープの為に使う」といった、募集側に不利な用途で使われる可能性がある為です。
完全に揃わない状況でのPTの仮組をしないというのは、応募側（傭兵側）からすると、理不尽な内容でPTが一方的にキャンセルされたりするのを出来るだけ避ける為です。

私が提唱した、２案目では、直前でのPTの会話を実現した形で提案していますので、ご検討ください。

Quote:

---

Originally Posted by noton-noton

引用割愛させていただきました

---

ご提示ありがとうございます。

サーバーレンジについては、運用メリット・コストメリットがはっきりしてますので、GP内でという方向性で問題ないと思います。

PTおよびチャット機能については、技術的に可能であることはわかりましたが、その機能がないことによるデメリットと開発コストとのバランス関係がいまいちわからないため、判断がつきかねます。




ってココまで書いて思ったのは、クライアント（発注）側の立場がいないとやりづらいんだってことですね。
↑のは思わずクライアント側に立ってしまいましたが。

うーん…静観してましたけどそろそろツッコミたくなってきた。
なんか物凄く根本的なとこ無視してるので勘違いな方向にぶっ飛んでる気がするんですよね。
開発がサーバガ+コストガのproc発動させてる原因をそもそもちゃんと予測出来てないんじゃないかと。

今回開発から出てる言葉は技術的な難色ではなく、設備的な難色です。
これは元スレの方でも話した通り、この機能を置くならCFマッチングサーバが条件として合うが、
そこに機能を足すことでの「CFマッチングサーバの」トラフィック増にサーバが耐えられないから足さないと厳しいってとこですよね。

じゃ、トラフィック増によってへたるのってどこ？っていうのを考える必要があると思います。
ネットワークに関しちゃ所謂ビッグデータなんていうFFの何倍もトラフィックのあるものでもイーサネットで賄えます。
つまりDC内の通信設備の問題じゃないんです。
まぁDC跨ぎとかになるとロケールの違いなんかもあるので通信設備的な問題も出るかと思いますが
CF機能の範囲の話であればわざわざコストの高いInfiniBandとか導入してもオーバースペックでしかない。

では問題はなに？って言うと、その増大したアクセスによるアクティブスレッド数の増加っていう点です。
ゲームなんかだとどうしてもKeep-Aliveな接続を必要とするので、それが一局集中することでCPU、メモリ負荷が跳ね上がる。
これによって本来提供しているCF機能にも遅延、障害を生む可能性があるレベルのトラフィック増が見えてるからこそ「サーバ増設」っていう見解なんだと思います。
おそらくこの要望に関してはここをクリアしない限り実装が難しいのかなと自分は考えますが、
エンジニアとして談義するならこの辺飛び越えて機能の話をしても…と言うのが正直な感想ですね。
エンジニアだとしてもインフラ考えたことのないコンテンツ系のアプリ屋さんの発想かなと。

まだワールド統合整理で空くサーバを当てて実現できないか→ワールド統合のネックは何か
とかの方が目がある様に思います。
また、そういう意味では元スレのタイトルは意外と的を射たものだったりしたなーと思ってます。

>not on-notonさん

ご説明ありがとうございます。
ほぼおっしゃってるイメージは掴めました。
特に募集側で固定の補充などでは便利そうです。
通常の募集板と並行してできるのは素敵ですね。
気になるのはやはり応募側の方でしょうか。
プリセットの項目も限界あるでしょうしね……

HarukaPhilantha　さんへ

募集前のチャット等については、技術的側面より、実際に機能として必要かどうか？
これをまず考えたほうが良いでしょうね。

折角機能があったとしても、募集が揃う前に離しても無駄

「よろしくー」しか伝えないのであるなら、中で揃ってからでも遅くない…など。

技術面と関係なく考えられます。


＞ってココまで書いて思ったのは、クライアント（発注）側の立場がいないとやりづらいんだってことですね。
スレットタイトルから、書き込みを遠慮されているのかもしれませんね。
色々な書き込みがあった方が盛り上がるので、私は歓迎ですけど


F-DUCTさんへ
ありがとうございます。
万能ではありませんからね。ただ無いよりはあった方が助かると思います。

Paradiceさんへ

ご意見ありがとうございます。
トラフィックの増加について懸念されているようですが、私はこれに対して楽観視しています。

理由の一つが、トラフィックが問題になるぐらい「募集が立ち」かつ「それに興味があるプレイヤー」が存在するなら、
そもそもこの機能が必要ないからです。
裏を返せば、そんなに利用者は増えない事が予測できます。

募集に集まらないから必要とされているのですからね。

また、最初の提案の時にも書きましたが、「パッチ後や混雑時には利用できないようにする」としています。

また現行のCFサーバーに影響があるなら、ほぼ同じ構成で専用のCF2を用意することで対応できるのでは無いでしょうか？
ご指摘のように、一つのサーバーへのトラフィックが問題なら、分散が一番効果があります。


＞ゲームなんかだとどうしてもKeep-Aliveな接続を必要とするので、それが一局集中することでCPU、メモリ負荷が跳ね上がる。
＞これによって本来提供しているCF機能にも遅延、障害を生む可能性があるレベルのトラフィック増が見えてるからこそ「サーバ増設」っていう見解なんだと思います。

CFサーバーにはサービスとして参照はありません。
（状況の表示がありますが、CFが直接返す必要が無い処理なのでここでは問題にしません）

基本的には参加への登録があるだけで、処理が終われば即切断です。
登録のタイミングは、負荷がかからないようなタイミングで遅延登録が可能です。
（ユーザーに挙動が見えないため）

また、CFへの登録を待つために、APサーバー＜＞CFサーバーのAliveをOnにする必要はないでしょう。

また、ワールドとの接続と違って、CFや募集は使い終われば直ぐに接続を切っても問題ありません。
ここがリアルタイム処理とは違うところです。

ところで、CFに影響がある予測ですが、どれぐらいの募集数の増加と、閲覧数の増加を見込んでの事なのでしょうか？
また、何故一極集中するのでしょうか？　この機能が実装されると、プレイヤーは一斉にCFに登録するのでしょうか？
CFの利用者が何％増えると、問題になるのでしょうか？

私は、Sモブハントのリアルタイム処理の方が、負荷がかかってると思います。

モブハンの負荷は自分が体感しやすいクライアントの負荷だからそう見えるだけですね
そもそもエリア内各所で100人くらいが同時に戦闘行為を行ったとしても集まってなければサーバ負荷がないと言うわけじゃないですよね。
なのでそれこそ「負荷はたいして変わらない」です。
まぁフィールド過疎り気味だから変わるってのは違う話なのでこれ以上はご自身で考えて欲しいですが。
対して、CFはどこにいるユーザだろうがアクセスでき、かつ状況のポーリング、マッチングのプッシュ等の双方向アクセスもある機能です。
サーバ同時ログイン数の多いゴールデンタイムに3割のユーザが利用した
として、どちらの負荷が高いかなんてのは言うまでもないですよね
且つ、あれはクロスワールドなのでそれがワールドの人数比例でさらに倍、3倍と言うものです。
ここに機能を足すと言うことは更にCFサーバへの負荷を上げると言うことになります。
先ほど3割としたものが仮に4割になったとしても相当なものですよね。この状況をさして「一極集中」と表現したまでです。
少なくともサーバ側で最も過負荷である部分はログインサーバかCFのどちらかと言うレベルだとは思います。
この様なユーザからも見えるところと開発の発言から類推して、と言うのが先の内容です。

あと、数字は1ユーザである自分には知り様もないですが、その質問でどんな答えを期待しているのでしょうか。

Paradice　さんへ
＞CFはどこにいるユーザだろうがアクセスでき、かつ状況のポーリング、マッチングのプッシュ等の双方向アクセスもある機能です。

CF機能は、CFサーバーがユーザーとは直接通信はしていないでしょうね。
募集情報をいったんAPサーバが受け取って、CFのキューにポストするだけじゃないかな？
（ここでAPとCFはいったん切断）

CFサーバーはCPUレベルのループではなく、１秒置き程度のゆっくりしたタイミングで処理
キューから募集データーを取り出せばいいのだし。（ここでは通信は発生しない）
非同期だから、（CPU・メモリ）リソースの許す範囲で順番にアクセスする事が仕様上許されます。

最悪、マッチング速度を遅くすることで、処理の時間当たりの負荷は下げられます。

マッチ後は、PT情報を処理用のプロセスキューにポスト、　
・APサーバーにクライアントで確認ダイアログを出す命令を送信、レスポンスを待つ（あくまでAPとクライアントの通信）
・失敗した場合（全員の同意を得られない）は成功している部分を、CFへ再ポスト
・成功した時はCF処理フェーズへ

相手のレスポンスが帰るまで、待つようなプログラム設計にはしてないと思いますよ。

もともとCFはクロスサーバーだから、機能を追加したら（能力を超える通信が）大幅に増えるというご意見にも疑問符が付きます。

ところで、CFでKeep-Alive Onが必要な部分はどこでしょうか？

＞あと、数字は1ユーザである自分には知り様もないですが、その質問でどんな答えを期待しているのでしょうか。

GTの募集数を観れば、おのずと数字が想定できませんかね？
約１０サーバー分の、エンドコンテンツの募集の数は幾つでしょうか？

ざっくりと２００前後ではないでしょうか？
２割増えても４０募集分

自動的に、その募集をCFに組み込んだとして、CFの利用が４０増えたら機能が止まるような話？？？

募集をCFに混ぜても大丈夫ではないですかね？

まぁ簡単に考えてもエリア移動で別サーバへの接続仕直しが発生し、且つその際にCFの申請状態は維持されてなきゃいけないってことは
CF登録のコンテンツ表示が出てる間、クライアントはCF用に1つスレッドを確保してます。
エリア移動中にシャキったとか、まぁ普通にプレイしてても経験しますよね

ということはゲーム本体を司るサーバプログラムとは切り離されたところでセッションをキープしてるのは明白です
これがCFとの継続的なセッションがある証拠かなと思いますが

少なくともマッチング完了してからコンテンツへの移動はクライアント処理です
マッチングの組み合わせそのものはキュー処理としてIDなりで行っているとしても
クライアントとのやり取りはリアルタイム性を保持してますよ？
このことはフォーラムひっくり返しても「取り消したのにマッチングされた」という話がないことからも間違いないと思います
少なくとも1秒もラグを持っているならクライアント処理で取り消してるのに通知を受け取るというアホな動作が起こりかねません
また接続しているセッションを右のサーバから左のサーバへクライアントに気付かれずなんて手法はやろうと思えばできなくはないでしょうが
新生時にシームレスを断念しているところからもそうではないと見てとれます

まぁとはいえあくまでも自分の憶測ですから正しいのかは不明ですが

募集の登録数だけが増えるトラフィックだと思ってるなら見積もりが甘々です
応募しようか閲覧していいのがないから閉じる
これだけでもアクセスは発生しますよね

たからこそ本当の負荷はユーザには「分からない」と言っているのですが

Paradice　さんへ
まず登録時には、キューへのポストで処理しているということでよろしいですね？

＞エリア移動中にシャキったとか、まぁ普通にプレイしてても経験しますよね
これは、通常のエリア処理とCFマッチングが別である事の証明でしかありません。

＞クライアントとのやり取りはリアルタイム性を保持してますよ？
DC内部のトラフィックのを問題にされてましたよね？
そこは（クライアント　APサーバ間）、最初から否定していません。

（募集が成立するまでセッションを維持する事はやらないでしょう、
３０秒間維持する通信が発生するのは、PTマッチングが終わった後ですよね？）


クライアントとAPサーバーの間なら、APサーバーは並列化されているので、
そこの通信が増えても、貴方が指摘しているセッションは増えても問題ないはずです。
（そのためのAP並列化だから）

＞このことはフォーラムひっくり返しても「取り消したのにマッチングされた」という話がないことからも間違いないと思います
取り消しができるということは、いったん仮マッチングが終了しています、動きとしては問題ありません。
（マッチングされて、確認ダイアログが表示されないと拒否できない）
全員が揃ったのを確認して、成功以外はすべて失敗する　という仕組みではないでしょうか？

いずれにしても、APとクライアント間が通信を維持してる間に、APとCFが通信維持しているという話ではないでしょう。
（そちらは維持する理由がありませんからね）

＞応募しようか閲覧していいのがないから閉じる　これだけでもアクセスは発生しますよね

ユーザーが増えて、アクセスが増えることを否定してはいませんよ。
システムを揺るがすような事が起きますか？　という事なのですが。

もしこれがCFに限った話なら、申し込みをするまでは通信は発生しません。（定型のあのメニューはクライアントが処理できるので）

募集の閲覧では通信が発生するので、減らす方法を考えるのがこのスレッドの目的ですよｂ
折角、このスレッドに参加していただけるのなら、成功する方へお知恵をお借りしたいと思います。

＞たからこそ本当の負荷はユーザには「分からない」と言っているのですが

このスレッドは、本当の負荷を暴く為にあるのではありません。
正確な事は判らない事は、わかった上でのスレッドです。＞※１参照

吉田Pがかつて何を想定した話か分かりませんが…以下

DCマタギをしない・グループ跨ぎもしない・相互閲覧する募集の数を減らす

これで幾らか減らす事が出来ると判断できます。
もしかしたら、前提条件が違えば、可能性もあるかもしれません。

その他に、募集データーのほうを参照するのではなく、傭兵（参加者）側を登録閲覧することで、
キャッシュを恩恵を大きくして負荷を減らせないか？　など

考えるのは、こういった方向性ではないですか？

場合によっては、設備の投資が必要かもしれませんが、過疎鯖問題の解決によって、過疎鯖への逆流が始まり、しいては土地問題も多少緩和するなど
設備投資を有効にすすめる手助けになるかもしれません。

ところでKeep-AliveがON必要な所はどこですか？
ご自分が出したのだから、きちんと説明して欲しいですね。
「負荷が増える」なんてのは誰でも言える事ですよ。

書いているないようさっぱりわからないのに
毎回覗いているます。

仕事でもないのに、こんなに真剣に考えてくれるユーザーがいるFF14ってすごいなって思います。
また、エンジニアってすごい人達だなって感心してしまいました！



運営さんも協力してくれるとイイですね！

いやホント仕事でもないしなんかこれ以上は不毛になりそうなんでここまでにしておきますが

・負荷量について
負荷量を明確な数字を求めたのはnoton-notonさんご自身です
自分で出した話をと人に言うならそういうとこもすり替えないで下さいね

・Keep-Aliveについて
既に書いています。
付け加えるなら少なくともサーバからの開線要求を受け付けるなんて非セキュアなプログラムで作られてることはまずないでしょうね。

あと大前提として先にも書いてますが「負荷が許容範囲を超える」というのは他あろう開発が発した言葉からの類推です
その負荷がかかるのがどこ？っていうそこを考えずにプログラムを論じても「だから無理だって」と開発に一蹴されるだけだと思うってのがツッコミのポイントです
これが現状の立ち位置である以上、そんなことはないといくら言おうがそこは覆らないし
今あるものの負荷が下がる訳でもない
それをプログラムで実現しようとするならそれこそ再新生のレベルの見直しがいるのかと思いますので、
ならサーバを増強できる道=ワールド統合等で他から回せるリソースがないのか、
という様な方がまだ現実味があるんじゃないのかと思うということです

Paradice　さんへ

募集やCFのマッチングの部分については、今回の提案の変更で何かしかの「増える要素」があるかもしれませんが、
マッチングが終わった後の動作については、従来とかわらないですよね？
方法がどうあれ関係ないといえるのではないでしょうか？


・応募が増えたら通信量が増える
・マッチング成功数が増えたから通信量が増える　
当たり前ですから、こんなことを指摘されているわけではないでしょう？



案１では、PT募集からCFに自動登録する　という内容ですが、

・募集登録の部分では、キューにポストするデーターが数バイト増えるだけで、（APとCF間）通信も即遮断だから、ご指摘の部分は増えませんよね？
・マッチング動作も非同期で通信は発生しない
・マッチング完了後の話は、今回とは関係ない。

どこにシステムを揺るがすような、通信の飛躍的増加する要素があるのでしょうか？

＞負荷量を明確な数字を求めたのはnoton-notonさんご自身です
負荷量が増えることを問題にしているのはParadiceさんですから、できるだけ具体的にかつどの部分かを提示して欲しいと思います。
根拠があっての事でしょう。

＞セキュアな通信　付け加えるなら少なくともサーバからの開線要求を受け付けるなんて非セキュアなプログラムで作られてることはまずないでしょうね。
クライアントとAPの間の話は今回関係ありませんよね？
この部分は常時接続でしょうし。
クライアントに「ダイアログを開く命令」というのは、通信は確立されている中での「コマンド送信」ですよ。

＞その負荷がかかるのがどこ？っていうそこを考えずにプログラムを論じても「だから無理だって」と開発に一蹴されるだけだと思うってのがツッコミのポイントです
で、どこですか？
今回、明確に増える部分と理由を提示できていないのは、Paradiceさんでは？

どこが増えるかがはっきりすれば、このスレでどうすれば減らせるかという話にもつながりますので、是非お願いしたいです。



＞それをプログラムで実現しようとするならそれこそ再新生のレベルの見直しがいる
プログラムでできる事を、サーバーの増強で何とかするのを論じるのはナンセンスです。

用語解説のようなことをしてみます。

●APサーバー（アプリケーションサーバー）　
・ユーザーとのやり取りをおこなうプログラムが搭載されているサーバー
・ある程度以上の規模になると、複数台が用意される

仮に1台で１００ユーザーを相手にする場合、同時接続が３０００人の場合、３０台必要となります。
チョコボ鯖という名称で、各ワールドを語ることが多いので単独と思われている方もいるかもしれませんが。実際にはサーバー郡と言えるでしょう。

ゲームの場合は常時接続でユーザーからの命令を待ち続けます。また、キャラクターが存在するワールドからのデーターをクライアントに送信します。

光のエンジニア達が戦っていると聞いてc(`･ω´･ c)っ≡つ
応援してます！！

こんにちは！よーやっと３連休です！('ω')ノ
ちょっと見れてなかった間にものすごく話が進んでておいつくのが大変だ。。＠＠

>notonさん
ご意見、ご提案ありがとうございます！
吉田P/Dの懸念であるDC内から同時アクセスのあるサーバを立てた場合に大量の参照が発生し、それに耐えられない可能性があるという説明について

・そもそも機能としての参照を制限する
・パッチ後や混雑時には利用できないようにする

という提案はとても理に適っていると思います。
3.0実装直後のいくつかのエリアのチャンネル化と同様の対応ですね。そもそも人が殺到するような状況であれば、この機能自体が必要ないというのはその通りかと思います。

その一方で、上記内容で実装された機能がほんとにユーザが必要としているものかどうか？の検討が必要とも思います。
技術的にこれなら可能だからといって実装したものがチガウソウジャナイ、だったら悲しいので。。
※そういう意味では、上述した一部エリアのチャンネル化もやはり一部ユーザから不満の声はあがりましたね。。

程度問題にもなるとは思いますが、この実装でどういった機能が提供され、それは本当に必要なものかどうかというのを利用するユーザ側の立場から考えてみたいとも思います。

＞スレットタイトルから、書き込みを遠慮されているのかもしれませんね。
そうかもしれませんね。ちょっと#1に補足しておきます(; ･`д･´)

＞Paradiceさん
ご意見ありがとうございます！

＞では問題はなに？って言うと、その増大したアクセスによるアクティブスレッド数の増加っていう点です。
＞ゲームなんかだとどうしてもKeep-Aliveな接続を必要とするので、それが一局集中することでCPU、メモリ負荷が跳ね上がる。
＞これによって本来提供しているCF機能にも遅延、障害を生む可能性があるレベルのトラフィック増が見えてるからこそ「サーバ増設」っていう見解なんだと思います。
＞おそらくこの要望に関してはここをクリアしない限り実装が難しいのかなと自分は考えますが、

そうですね、ここがまさに僕の考えていただから厳しいのでは？の部分です。
APサーバ <--> CF(あるいは募集)サーバ間の通信がKeepAliveである必要はないと思いますが、単純な参照数の増加がそもそもの懸念になると思います。

※KeepAliveが必須なのはあくまでクライアント <--> APサーバ間であり、既存のAPサーバ間 <--> 募集掲示板は一定期間でのポーリング+ユーザリクエストごとの通信だし
CFについてはちょっとわからない、、というかKeepAliveな気もしますが、今回新設される機能はあくまでも既存のCF機能を流用したCF2であり、KeepAliveではない実装にすればよい、という考え方もできるとは思います。
負荷をできるだけ減らすような実装の工夫が必要ですね。

#言葉の定義#
ちょっと整理しておきましょう。
ワールド：Chocobo,Bahamut,Carbuncleなど、それぞれの実際のキャラクターが所属するプレイヤーにとっての世界。
CFグループ：Mana,Gaia,Elementalなど。いくつかのワールドを束ねたもの。だいたい１CFグループに10ワールドほどが存在し、CFではワールドを飛び越えてCFグループ内でのマッチングが行われる。
DC:データセンター。CFグループが稼働する物理的な存在。現在は日本DCと北米DCがあり、もうすぐ欧州DCができる。
#今回ぼくたちが欲しいのは[「ワールド跨ぎ = CFグループ内」のPT募集機能]という風に理解しています。DC跨ぐのはそもそも要求されてないし、物理的にもハードルが高いので考慮外ですかね。

ついでに。
サーバー：FFXIVプレイヤー的には上述した「ワールド」と同義（＝チョコボ鯖）。ただしこのスレッドではエンジニアとして「サーバ」が頻出するので補足しておきます。
基本的には、ホストOS（多くはLinux）が動いている１台のマシン（物理・仮想問わず）を指し、実装される機能ごとに複数のサーバが接続され、上述したワールドが構成されています。
notonさんの説明にある「APサーバー」もその一つで、実際にはAPサーバ（１台～必要なだけの複数台）が前面に立ちユーザからのアクセスを受け付け、それを裏側にいるデータベースサーバ、キャッシュサーバ、その他機能ごとのサーバとやり取りをしその結果をまたAPサーバ経由でユーザへ返却するという構成になっています（いるハズです）。１ワールドは複数台のサーバから構成されているということですね。

技術に詳しく無いヒトの感想です。

募集を仮想コンテンツとしてCFの処理フローに載せる方式だと理解しました。
その場合は、CFの作りがポイントだと思います。

もし、CFのマッチングがコンテンツを軸にする作り（コンテンツ毎にジョブ(プロセス)など）だった場合、
対応コンテンツ数を動的に変更できず、募集を仮想コンテンツとしてCFの処理フローに載せる方式は破綻する可能性があります。

だとすると、新規にサーバ跨ぎのPT募集を構築した方が、既存への影響も最小に出来るし、導入(運用)しやすいと思います。

もし、コストを重視するのであれば、零式と練習モード（実装検討中？）の各フェーズをCF対応コンテンツにしてもらえば、
サーバ跨ぎのPT募集（簡易版）と変わらない気がしました。

btk さんへ
まとめどうもです。

私からは２つの方法を提示しています。

●従来の募集とCFを同時に募集ができ、CF機能を使う場合は、任意選択、マッチングはCFに委任
・他鯖の募集の閲覧がそもそも無いため、当初の最大の懸念点を根本から取り払っている
・固定補充等に最適
・CF登録側にも、ある程度のマッチング条件を入れてもらう。
・こういった仕様の為、細かいマッチング条件は設定できない。

●募集側を閲覧するのではなく、応募側をPT側からスカウトするような形にする
・これもPTの参照を仕様から取り除くことで、最大の懸念点を払拭
・そのかわりに、個人を登録する募集板を作成
・登録されたデーターはキャッシュに最大限の効果があるため、通信問題の軽減が可能
・募集先・目的など、最初から分割して参照の入り口を作ることで、負荷を分散可能
・個人掲示板の作成、PTからピックアップするなどの、新規機能が必要
・使い方によっては、サーバーを跨って「固定」を組むことが可能

ご検討ください。

今回のスレッドで議論されている部分の解説

募集を開く
CFの登録

この２つを考察します。

募集を開く：
この命令をAPサーバーが受け取った後、最新募集状況を募集を管理しているサーバーに問い合わせてます。
募集を受け取ったサーバーが処理を戻すまで、APサーバーは結果を待っています。
準備が整ったらクライアントに情報を返却し、募集一覧がクライアントに表示されます。

募集データーの準備処理が集中すると、その間の通信プロセスが重なってパフォーマンスが落ちる。
今回、懸念されている内容のひとつです。
なお、この処理の間は、通信は接続したままだと思われます。

直ぐにレスポンスを返す必要があるために、このような方法がとられます。

CFの登録：
CF登録するときは、APサーバーは、募集を管理するサーバーに、キャラクターのID、ジョブ、IL、レベル、希望ID　（PTの場合はそれらをまとめて）
CFの情報が記録されている場所へ配置します。
この処理が終わった後は、通信を一旦きります。（募集が必ずしもマッチするとは限らないから）

CF側は、CF応募データーに変化があると、マッチング処理を開始します。
（大量に集中するときは、速度を調整するなどしていると考えられます）

マッチングした場合は、マッチング処理に移行します。

Quote:

---

Originally Posted by TonPoo

技術に詳しく無いヒトの感想です。

募集を仮想コンテンツとしてCFの処理フローに載せる方式だと理解しました。
その場合は、CFの作りがポイントだと思います。

もし、CFのマッチングがコンテンツを軸にする作り（コンテンツ毎にジョブ(プロセス)など）だった場合、
対応コンテンツ数を動的に変更できず、募集を仮想コンテンツとしてCFの処理フローに載せる方式は破綻する可能性があります。

だとすると、新規にサーバ跨ぎのPT募集を構築した方が、既存への影響も最小に出来るし、導入(運用)しやすいと思います。

もし、コストを重視するのであれば、零式と練習モード（実装検討中？）の各フェーズをCF対応コンテンツにしてもらえば、
サーバ跨ぎのPT募集（簡易版）と変わらない気がしました。

---

TonPoo　さんへ　ご意見ありがとうございます。

＞もし、CFのマッチングがコンテンツを軸にする作り（コンテンツ毎にジョブ(プロセス)など）だった場合、
＞対応コンテンツ数を動的に変更できず、募集を仮想コンテンツとしてCFの処理フローに載せる方式は破綻する可能性があります。

この部分を考えていたのですが、私が、想定されていることが正確に把握できていないと思う中で意見を書きます。
・マッチング処理とコンテンツは、もともと別々に独立していると考えられます。
・サーバー跨ぎの募集は、そのままだと閲覧によるアクセスの過多による問題が発生する可能性があり、なんらかの制約を設ける必要がある。
・CFだとジョブを選ぶことができないので、そのままだと使えない。
・箱問題は、マッチングする前に確認が必要

こんな感想をもちました。

一個質問なんですがこのスレッドで話されているような
PT募集なのか特殊なCFなのかは別にして
PTを組んでコンテンツに入るまでに時間が掛かる問題を解決する仕組みを
利用したいプレイヤーのおおよその数というか割合みたいなものって限定できないですかね?
例えば零式の様な高難易度コンテンツにこそ必要だから
実装された場合その機能を使えるのは前提クエストをクリアしたプレイヤーのみとかにして
利用者数を限定することでサーバー間募集であれ特殊なCFであれ
サーバーに対する負荷が軽減されるのであれば良いかなと素人ながら思ったとです

サーバー跨ぎで一つ疑問。

名前どうするんだろ？
同姓同名居たらかち合いそうな気もする…………。

Quote:

---

Originally Posted by aqua_steve

一個質問なんですがこのスレッドで話されているような
PT募集なのか特殊なCFなのかは別にして
PTを組んでコンテンツに入るまでに時間が掛かる問題を解決する仕組みを
利用したいプレイヤーのおおよその数というか割合みたいなものって限定できないですかね?
例えば零式の様な高難易度コンテンツにこそ必要だから
実装された場合その機能を使えるのは前提クエストをクリアしたプレイヤーのみとかにして
利用者数を限定することでサーバー間募集であれ特殊なCFであれ
サーバーに対する負荷が軽減されるのであれば良いかなと素人ながら思ったとです

---

＞PT募集なのか特殊なCFなのかは別にして、
＞PTを組んでコンテンツに入るまでに、時間が掛かる問題を解決する仕組みを
＞利用したいプレイヤーの、おおよその数というか割合みたいなものって限定できないですかね?
（句読点をこちらでいれました）

どの程度必用としてるのでしょうかね？
ただ、比較的アクティブ率が高いと思われるアレキ組みの利用希望者が多いのはないでしょうか？

＞例えば零式の様な高難易度コンテンツにこそ必要だから
＞実装された場合、その機能を使えるのは前提クエストをクリアしたプレイヤーのみとかにして、
＞利用者数を限定することで、サーバー間募集であれ特殊なCFであれ、
＞サーバーに対する負荷が、軽減されるのであれば良いかなと素人ながら思ったとです
（句読点をこちらでいれました）

利用者の個別情報を管理する手間が増えるので、相殺されてしまうような気がします。

補足しときます。
CFの処理は、受付は申請単位 、マッチングはコンテンツ単位と想像しました。なんとなくですがコンテンツ毎に待行列がある方が素直だと思います。

Quote:

---

Originally Posted by MisatoMisa

サーバー跨ぎで一つ疑問。

名前どうするんだろ？
同姓同名居たらかち合いそうな気もする…………。

---

確か新生前に吉田Pが、新生ではキャラ毎に固有IDで管理しているので、
システム的には、同一ワールド内での同姓同名は可能になっている、
と言ったことを言われていたと思います。

UI的にはID表示していないので、その辺りを改修しないと使えないとは思いますが...

自分に割り当てられているIDって何だろう？ちょっと気にはなりますね＾＾；

Quote:

---

Originally Posted by Matthaus

確か新生前に吉田Pが、新生ではキャラ毎に固有IDで管理しているので、
システム的には、同一ワールド内での同姓同名は可能になっている、
と言ったことを言われていたと思います。

UI的にはID表示していないので、その辺りを改修しないと使えないとは思いますが...

自分に割り当てられているIDって何だろう？ちょっと気にはなりますね＾＾；

---

素直に考えるならロドストのIDじゃないかな・・・？

Quote:

---

Originally Posted by MisatoMisa

サーバー跨ぎで一つ疑問。

名前どうするんだろ？
同姓同名居たらかち合いそうな気もする…………。

---

ソーシャルゲームを始めるとき入力する名前は、重複をチェックしておらず、キャラクターの一意のデーターはＩＤ番号を付与します。
ＦＦの場合、同サーバー内では同名チェックをしているようなので、サーバー内では大丈夫ですが、グループ内だと引っかかる可能性が…

確認してはいないのですが、同名チェックの範囲が「グループ」だと、この問題は起きませんが、ここは不明です。
尚、もっとも重要なＩＤは、名前と違ってユニーク属性（１個しかない事が保証されている）なので、システム的な問題は発生しないと思われます。

同名が出てきたときに、やや問題なのはチャットでしょうかね？
どちらの発言かわからない…
その場合、システムが名前に番号を振ってくれればいいのですが…

｛同名の人間は、ＣＦならばマッチングしないという裏プログラムで回避できますが（苦笑）｝