質問編集履歴
2
書式の改善
test
CHANGED
File without changes
|
test
CHANGED
@@ -1,57 +1,3 @@
|
|
1
|
-
|
1
|
+
当サイトでの活動を終了しますので
|
2
2
|
|
3
|
-
|
4
|
-
|
5
|
-
|
6
|
-
|
7
|
-
###発生している問題・エラーメッセージ
|
8
|
-
|
9
|
-
個人で作成しているオンラインのカードゲームがあります。
|
10
|
-
|
11
|
-
サーバー側はよくあるLinuxのレスポンシブコードではなく、同じWindowsのアクティブプログラム
|
12
|
-
|
13
|
-
|
14
|
-
|
15
|
-
サーバー側でマッチング配列を作ってそれをクライアント側にオートマッチングして分配して、勝負が終わったら次の符号へ…というのを繰り返すのが基本的な仕様なのですが、対戦ルームの進行が1vs1で個々に独立しているため様々なため、ノーマナープレイヤー対応のためのログを取りながら、どこでサーバーのメモリにトークン的なリセットをかけてよいのかが分かりません。(最初の方の符号で作られた対戦が想定外に長引くと、サーバープログラムからリセットを掛けると途中で追い出してしまう格好になってしまう)
|
16
|
-
|
17
|
-
|
18
|
-
|
19
|
-
こういう場合、オンラインゲームとしては長引き過ぎのルームをメモリ上で移動する、対戦中のだけ残してサイクルをステップ単位で空白の処理(無視)する、などの方法も思いつきますが、こうして断片化したゲームルームがあちこちにできると、どう考えても同時接続者が増えると派手にメモリリークするのは明らかです。
|
20
|
-
|
21
|
-
|
22
|
-
|
23
|
-
商業の一般の同接が万を超えるようなゲームではどのような処理を行っているのでしょうか?(あるいは安価に借りられる高性能ゲーミングサーバーの構成でもあるのでしょうか?)
|
24
|
-
|
25
|
-
それほど頻繁にアップデートするつもりはありまえんので、出来ればメモリ開放のためだけのメンテナンスは出来るだけ抑える(せいぜい月1ぐらい)にしたいなと思っています
|
26
|
-
|
27
|
-
ご存知の方お教え頂けるとありがたいです
|
28
|
-
|
29
|
-
|
30
|
-
|
31
|
-
###試したこと
|
32
|
-
|
33
|
-
長引き過ぎのルームをメモリ上で移動する、送受信するパケットの基本丸め処理、クライアント側で完了出来ることはできるだけ任せる、対戦中のだけ残してリセットサイクルをステップ単位で空白の処理とする、ゲームに1日中張り付いていたり長時間放置と思われるプレイヤーの接続優先順位を自動的に下げる、MOルーム構成のパーシャル化、サーバーを比較的高額のものに変える、など…
|
34
|
-
|
35
|
-
|
36
|
-
|
37
|
-
###処理概要(中間のゲーム特有の分岐や暗号化/複合化・アプリ間の照合などは除いています)
|
38
|
-
|
39
|
-
1.(DirectXの初期化、登録ログイン情報のロードなどを行って)クライアントソフトがマッチング要求をサーバーに送る
|
40
|
-
|
41
|
-
2.サーバーソフトが順次検索でマッチング相手に対する最適ルームインデックスを生成しそのプリセット情報をクライアントソフト側に戻す(+再起動時は全リセ)
|
42
|
-
|
43
|
-
3.プレイヤー同士がゲームを始める
|
44
|
-
|
45
|
-
4.3.の対戦は独立進行でチャット、運営ポップアップメッセ等を除いて特に割り込みなし。マルチルールですが個別にロードし直しているのでこれも独立処理。
|
46
|
-
|
47
|
-
5.対戦が終わったサーバー上のメモリエリアと対戦が終わっていないメモリエリアが断片化した状態で、新たにログインしてきたプレイヤーのマッチングを生成する→ここでメモリリークその1
|
48
|
-
|
49
|
-
6.対戦が完全に終わったフィールドは一斉リセットを掛けることでプログラムがサーバーメンテナンスする
|
50
|
-
|
51
|
-
7.このタイミングを密にすると通常の対戦応答へ割り振れる負荷が減り、疎にするとメモリリークその2になる
|
52
|
-
|
53
|
-
8.同時接続者数が少ないと各種アルゴリズムによる最適化で何とかなるが、多いとアルゴリズムが新規エントリの割り込みでいつまでも終わらないという逆効果に困惑
|
54
|
-
|
55
|
-
9.ピアツーピアにすればいいんですが不正対策に不安が…
|
56
|
-
|
57
|
-
10.現状、サーバーを強化してごまかしている
|
3
|
+
恐れ入りますが削除させていただきます
|
1
追記
test
CHANGED
File without changes
|
test
CHANGED
@@ -6,9 +6,15 @@
|
|
6
6
|
|
7
7
|
###発生している問題・エラーメッセージ
|
8
8
|
|
9
|
-
個人で作成しているオンラインのカードゲームがあります
|
9
|
+
個人で作成しているオンラインのカードゲームがあります。
|
10
|
+
|
11
|
+
サーバー側はよくあるLinuxのレスポンシブコードではなく、同じWindowsのアクティブプログラム
|
12
|
+
|
13
|
+
|
10
14
|
|
11
15
|
サーバー側でマッチング配列を作ってそれをクライアント側にオートマッチングして分配して、勝負が終わったら次の符号へ…というのを繰り返すのが基本的な仕様なのですが、対戦ルームの進行が1vs1で個々に独立しているため様々なため、ノーマナープレイヤー対応のためのログを取りながら、どこでサーバーのメモリにトークン的なリセットをかけてよいのかが分かりません。(最初の方の符号で作られた対戦が想定外に長引くと、サーバープログラムからリセットを掛けると途中で追い出してしまう格好になってしまう)
|
16
|
+
|
17
|
+
|
12
18
|
|
13
19
|
こういう場合、オンラインゲームとしては長引き過ぎのルームをメモリ上で移動する、対戦中のだけ残してサイクルをステップ単位で空白の処理(無視)する、などの方法も思いつきますが、こうして断片化したゲームルームがあちこちにできると、どう考えても同時接続者が増えると派手にメモリリークするのは明らかです。
|
14
20
|
|
@@ -32,16 +38,20 @@
|
|
32
38
|
|
33
39
|
1.(DirectXの初期化、登録ログイン情報のロードなどを行って)クライアントソフトがマッチング要求をサーバーに送る
|
34
40
|
|
35
|
-
2.サーバーソフトが順次検索でマッチング相手に対する最適ルームインデックスを生成しそのプリセット情報をクライアントソフト側に戻す
|
41
|
+
2.サーバーソフトが順次検索でマッチング相手に対する最適ルームインデックスを生成しそのプリセット情報をクライアントソフト側に戻す(+再起動時は全リセ)
|
36
42
|
|
37
43
|
3.プレイヤー同士がゲームを始める
|
38
44
|
|
39
|
-
4.対戦
|
45
|
+
4.3.の対戦は独立進行でチャット、運営ポップアップメッセ等を除いて特に割り込みなし。マルチルールですが個別にロードし直しているのでこれも独立処理。
|
40
46
|
|
41
|
-
5.対戦が
|
47
|
+
5.対戦が終わったサーバー上のメモリエリアと対戦が終わっていないメモリエリアが断片化した状態で、新たにログインしてきたプレイヤーのマッチングを生成する→ここでメモリリークその1
|
42
48
|
|
43
|
-
6.
|
49
|
+
6.対戦が完全に終わったフィールドは一斉リセットを掛けることでプログラムがサーバーメンテナンスする
|
44
50
|
|
45
|
-
7.
|
51
|
+
7.このタイミングを密にすると通常の対戦応答へ割り振れる負荷が減り、疎にするとメモリリークその2になる
|
46
52
|
|
53
|
+
8.同時接続者数が少ないと各種アルゴリズムによる最適化で何とかなるが、多いとアルゴリズムが新規エントリの割り込みでいつまでも終わらないという逆効果に困惑
|
54
|
+
|
55
|
+
9.ピアツーピアにすればいいんですが不正対策に不安が…
|
56
|
+
|
47
|
-
|
57
|
+
10.現状、サーバーを強化してごまかしている
|