鯖統合かＰＴ募集を別鯖からでも入れるようにしてほしい

[Nivalis]

省略させていただきます

だれがいつチャットメッセージを送るごとにセッションをはりなおすといったのでしょうか？

既存のシステムに組み込むとしたらセキュリティの関連から募集のチャットだけを別にするという事はないと思います。
つまり、集中的に通信をしているサーバー経由、ユーザーのセッションは増えません。
但し、新しく組むにしても、既存のシステムを利用するにしてもサーバー間のセッションは増えます。
また、職、ILなどといった情報はどうするのですか？

最大人数の決まっているCFのシステムの1枠分は募集した段階で占有されてしまうのではないですか？

募集が多いのでIDへ入れません
納得できますか？

また、サーバー間PT募集の通信だけ迂回させて接続はセキュリティ上しないでしょう
あとはCF枠を使わないように新しく作るしかありませんが、何処まで修正が必要なんでしょうかね？
開発にしかわかりません。

尚、解ってない方に説明するほど面倒な事はありませんのでこれ以上は返信しません。

[Silvershark]

確固たる証明はできませんが、募集の数、同時接続の数、サーバー数、そして必要となるサービスの内容から推測しています。

意味のない技術的な話はやめませんか？
noton-notonさんもシステムを何も知らないのに自分の想定が正しい的な書き込みは専門的知識がない人に混乱させるだけ
全鯖にキャラ作ってGTの時間毎の募集の発生／募集の消化／キャンセル等々を監視しない限りそんな
想定はできないですよ。その程度の情報を見たところでも大した推測はできないですけど。
(ぶっちゃけどの程度の数字で推測したか聞きたいですがやめときます)

＞現状のワールドサーバーにそのような余裕があるとは思えません
1募集に必要なメモリは１ｋbにも満たないと思われます。１００００万件で１０Mbです。余裕ではないでしょうか？

何かの公開情報をもとにした推測ですか？
1KB未満でどの程度の負荷だから10MBは余裕という推測ですか？


早急にCF対応して周制限はどうするの？自分たちはこんな形にしてほし！こんな形のは嫌だとか話せば良くないですか？

[MisatoMisa]

詳細スペックはスクエニが公開しないとわかりませんね。

PT募集&CF複合システム出来ませんかでいいような？

あとは統合のほうは単に休止者いるだけの可能性があるから、
やらないとは思う。
※3.1で復帰者いればそれだけ混乱になるかと。

[noton-noton]

また、職、ILなどといった情報はどうするのですか？

募集が多いのでIDへ入れません
納得できますか？

また、サーバー間PT募集の通信だけ迂回させて接続はセキュリティ上しないでしょう

尚、解ってない方に説明するほど面倒な事はありませんのでこれ以上は返信しません。

＞既存のシステムに組み込むとしたらセキュリティの関連から募集のチャットだけを別にするという事はないと思います。
＞つまり、集中的に通信をしているサーバー経由、ユーザーのセッションは増えません。

そうですね。ふえませんね。

＞但し、新しく組むにしても、既存のシステムを利用するにしてもサーバー間のセッションは増えます。

募集が増えればデーターのアクセスは増えるでしょう。
問題は、どのくらい増えるか？　ということではないですか？
そもそも、募集もCFもチャットなんて発生しないですよね？

＞また、職、ILなどといった情報はどうするのですか？
職　INDEXで1バイト　IL余裕をもって2バイト　　計3バイトです。　何か問題でも？

＞最大人数の決まっているCFのシステムの1枠分は募集した段階で占有されてしまうのではないですか？
CFの最大数が埋まるほど、アレキHに募集があるといいのですが（苦笑

＞募集が多いのでIDへ入れません
＞納得できますか？

現状＠１がこなくて2時間待ちなのですから・・・
最大コンテンツ処理数が問題になる話というのは、今回の拡張募集の件と関係ありますか？

「募集が多い」とコンテンツに入れない？　どんな因果関係があるのんでしょう？
意味不明ですね。

＞また、サーバー間PT募集の通信だけ迂回させて接続はセキュリティ上しないでしょう
ご自分で言い出して、「しないでしょうね」とはこれいかに？

サーバーとサーバー間の通信にグローバル通信が必要な前提になっているようですが、実際はSANで組まれたローカルネットワークだと思いますよ。

＞尚、解ってない方に説明するほど面倒な事はありませんのでこれ以上は返信しません。

＞また、職、ILなどといった情報はどうするのですか？＜－苦笑

[noton-noton]

意味のない技術的な話はやめませんか？
全鯖にキャラ作ってGTの時間毎の募集の発生／募集の消化／キャンセル等々を監視しない限りそんな

何かの公開情報をもとにした推測ですか？
1KB未満でどの程度の負荷だから10MBは余裕という推測ですか？


早急にCF対応して周制限はどうするの？自分たちはこんな形にしてほし！こんな形のは嫌だとか話せば良くないですか？

＞全鯖にキャラ作ってGTの時間毎の募集の発生／募集の消化／キャンセル等々を監視しない限りそんな
こういった事は必要ありませんから、それを想定した危惧も必要ありません。

キャラを作るというのが謎ですが、必要なデーターは、キャラクターのID番号と募集に必要な付随するデーター程度でしょう。

＞1KB未満でどの程度の負荷だから10MBは余裕という推測ですか？
PT募集板で新規募集を開いてください。
・行き先　IL等の条件　募集分　募集職　募集キャラID
これにあと、募集時刻
これらから１ｋ程度と計算しています。　必要のないデータは極力省くでしょうし、募集にこれ以上のデーターは必要ないでしょう。

（同時に）１００００万の募集でも　１０MB程度のメモリしか必要ないということです。

＞
そしてこのデータは「リアルタイム処理」が必要ないデーターです。

＞負荷
マッチングそのものには、通信処理は発生しないので、負荷はほぼ０でしょう。

わかりやすい例おしてエクセルを使います。
Aセルに「ナ・戦・暗・竜・モ・忍・召・黒・機・詩・白・学・占」の文字からひとつをランダムに選んで１００００行埋めてください。
データー抽出機能をセルの上部に設定してください。
ジョブを選んで表示！　処理にどの程度かかりましたか？
Bセルに希望IDをいれてください。実際にはID番号になります
条件が幾つか増えたところで、一瞬でおわるでしょう。
例としてエクセルを使いましたが、実際にはサーバー内のメモリに直接処理をするでしょうから、CPUにとってこの程度の作業は負荷にはならないでしょうね。

※サーバーでエクセル使っているとかそういう話ではないので、念のため。

[noton-noton]

＞早急にCF対応して周制限はどうするの？自分たちはこんな形にしてほし！こんな形のは嫌だとか話せば良くないですか？

募集の項目に、「外部サーバーも利用する」というチェックボックスの追加（パッチ直後、混雑時は利用できない）

募集条件の追加　
１）目的：練習（初期）　練習（中盤）　練習（クリア目的）　クリア済みのみ　なし
２）報酬について：未クリアのみ、4人までクリア済み可、無制限

登録しても、ローカルでの募集を優先するため、3分程度は外部サーバー機能は使わない
ローカルでメンバーが追加されると、外部サーバーへの登録は中止される
募集の条件ダイアログを開くと、外部サーバー登録は中止される


CF側、登録するときに、上で追加された条件を追加情報として設定してから登録
あとは吉報を待つ

[Asys]

内部詳細を知らない者同士で技術的な話をしたところで結論は出ない、というか現状上げ足の取り合いみたいになっているので皆で案出ししてイイと思ったら「いいね！」入れて、ここはこうした方がイイかもねみたいな意見を積み重ねていくスタンスがいいと思いますよ。
建設的に進めていければ熱意に押される形で公式にレスポンスがあるかもしれないですしね。

[Ran-Ran]

＞負荷軽減の為にDC別にロビーサーバを分けた
ロビーサーバーは常にアクセスが集中し、また高速のレスポンスが要求差される場所です。（DB参照も発生します。）

募集・CFマッチングは、そういう高速なレスポンス性は要求されません。

ではもう一つ
これは引用の一つ前のレスにて記載した事ですが、CFのマッチングはDC内に限定しているのですが、サーバ間PT募集ってどの範囲を希望して仕様を提示していますか？
CFに対する追加機能であるとすればDC内限定になるので特定の募集ではDC内PT募集をして欲しいという要望だけで済むと思います
DCを跨いで、つまりエレメンタルやガイアのDCからチョコボや神竜に対して募集出来る様にしろ！という提案なら、データ通信の負荷状況を鑑みると無理だと運営は判断しているかと推測します。

また、別レスにてチャットは発生しないとか言ってますけど、PT募集ではチャットは発生していますよね？
PT募集では要求ILを指定した際に「禁断しているタンクは連絡下さい」といった文章も散見しますが、他サーバから参加したメンバーの装備状態を確認するのはどうお考えでしょう？
技術者気取りで色々投稿されていますが、通信方式及び通信している内容、それに伴う負荷状況全てを把握していない限り断言は出来ないと思います。
それをさも「～は出来る」と発言されていますが、パケット解析でもしたのでしょうか？
あくまで「こうして欲しいな」という要望や「実装して貰えるとすれば同一DC内で良いかと」といった提案ならともかく、不確定要素が多々ある現場で断定されては議論とはならないと感じます。
仕様に絶対の自信があるのであれば、仕様書を吉田Pに郵送した方が進展はあるかと思いますが、如何でしょうか？

[Silvershark]

確固たる証明はできませんが、募集の数、同時接続の数、サーバー数、そして必要となるサービスの内容から推測しています。

具体的にどのような数字でどのような推測をしてのか教えてください。
必要となるサービスとはなんでしょう？数字と必要となるサービスがどのように関係してるのでしょうか？

＞現状のワールドサーバーにそのような余裕があるとは思えません
1募集に必要なメモリは１ｋbにも満たないと思われます。１００００万件で１０Mbです。余裕ではないでしょうか？
PT募集板で新規募集を開いてください。
・行き先　IL等の条件　募集分　募集職　募集キャラID
これにあと、募集時刻

1KB未満度いう内訳をお願いします。何がどのぐらいのサイズですか？
余裕というのは何が余裕なのでしょうか？

あと、マッチングのバッチ処理はどのくらいの間隔で起動するんですか？
ネトゲの自動マッチングでバッチ処理ってイメージわかないです。

これぐらいの数字が出せないならいい加減なことをいうのは止めた方がいいですよ。
引っ込みつかないのは分かりますが、話題を戻そうとしてるの察してください。

自分もこれで最後にします。このスレが運営の間で笑いのネタになっていないことを祈ります。

[noton-noton]

具体的にどのような数字でどのような推測をしてのか教えてください。
必要となるサービスとはなんでしょう？数字と必要となるサービスがどのように関係してるのでしょうか？

1KB未満度いう内訳をお願いします。何がどのぐらいのサイズですか？
余裕というのは何が余裕なのでしょうか？

あと、マッチングのバッチ処理はどのくらいの感覚で起動するんですか？
すぐには募集に登録されないとかひどいシステムですよ

これぐらいの数字が出せないならいい加減なことをいうのは止めた方がいいですよ。
引っ込みつかないのは分かりますが、話題を戻そうとしてるの察してください。

逆にお聞きしたいのですが、何をすれば１ｋｂ以上のデータになるのでしょうか？

以下見積もりです。

PT8人分のID　４X8
募集主名前文字列　２４（いらないかも）

現在の状況　
・職業　１X8
・レベル　2 x8

募集職業
職業　４X8　（ビット利用）　

平均レベルアイテムあり・なし　１
必要レベル　２
募集文字列　１２８
登録日時　４
言語設定　４
初見～のチェックボックス　４（ビット利用）
目的のレイド　INDEX　２

（数字の単位はバイト）

一般にこういったデーターは構造体というメモリブロックに入れられて、
配列処理で検索します。
１００００万件の配列検索程度は、「コンピューター」に負荷がかかるような処理ではないのです。
（これをリアルタイムにユーザーに伝えるのであれば、話は違いますがマッチング処理はそうではないからです）

上の説明でわからないなら、これ以上やさしく説明するのは無理かな。


3分程度の時間を置くのは、募集の登録をやった後、直ぐに修正など繰り返す動作が考えられるためです。
そこで3分ほど募集の内容に変更が無いことを確認してから、外部サーバーへのPT検索を実行します。
（また、サーバ内の希望者を優先するため）

こういう間隔を置いてから検索処理をおこなうのは負荷軽減で普通にあります。