PC 版 MCC で検索サーバに制限をかける

2020年7月21日 20:32

PC版 MCC に Halo3 が追加された。かつて最もやりこんだゲームが約10年ぶりにプレイできるようになったのは感慨深い。

が、1つ問題がある。それは人口不足によりマッチングがかからないことだ。PC版MCC では ping 値をベースに検索をかけるサーバを制限している。そのため過疎状態のサーバを検索対象とすると、今検索しているサーバにはプレイヤーがいないが他のサーバは ping 値が遅いから検索しないというループに陥り、永遠にマッチングしない状態になる。というわけでそれを回避するために検索するサーバに制限をかける方法について書く。

tl;dr

1. 管理者権限を与えたエディタで C:\Windows\System32\drivers\etc\hosts を開く

2. 以下を追加する

0.0.0.0 pfmsqosprod.eastus.cloudapp.azure.com
0.0.0.0 pfmsqosprod.eastus2.cloudapp.azure.com
0.0.0.0 pfmsqosprod.northcentralus.cloudapp.azure.com
0.0.0.0 pfmsqosprod.centralus.cloudapp.azure.com
0.0.0.0 pfmsqosprod.southcentralus.cloudapp.azure.com
0.0.0.0 pfmsqosprod.westus.cloudapp.azure.com
0.0.0.0 pfmsqosprod.northeurope.cloudapp.azure.com
0.0.0.0 pfmsqosprod.westeurope.cloudapp.azure.com
0.0.0.0 pfmsqosprod.eastasia.cloudapp.azure.com
0.0.0.0 pfmsqosprod.southeastasia.cloudapp.azure.com
0.0.0.0 pfmsqosprod.japanwest.cloudapp.azure.com
0.0.0.0 pfmsqosprod.japaneast.cloudapp.azure.com
0.0.0.0 pfmsqosprod.australiaeast.cloudapp.azure.com
0.0.0.0 pfmsqosprod.australiasoutheast.cloudapp.azure.com
0.0.0.0 pfmsqosprod2.australiasoutheast.cloudapp.azure.com
0.0.0.0 xblcxplatqos-brs-9-18-2-0.cloudapp.net
0.0.0.0 xblcxplatqos-scus-9-18-2-0.cloudapp.net
0.0.0.0 xblcxplatqos-cus-9-18-2-0.cloudapp.net
0.0.0.0 xblcxplatqos-eus-9-18-2-0.cloudapp.net
0.0.0.0 xblcxplatqos-neu-9-18-2-0.cloudapp.net
0.0.0.0 xblcxplatqos-jae-9-18-2-0.cloudapp.net
0.0.0.0 xblcxplatqos-ause-9-18-2-0.cloudapp.net
0.0.0.0 xblcxplatqos-seas-9-18-2-0.cloudapp.net

3. 検索したくないサーバの行を残して、検索したいサーバの行を消す or 行頭に # をつける

下は westus サーバのみを検索するときの例。

0.0.0.0 pfmsqosprod.eastus.cloudapp.azure.com
0.0.0.0 pfmsqosprod.eastus2.cloudapp.azure.com
0.0.0.0 pfmsqosprod.northcentralus.cloudapp.azure.com
0.0.0.0 pfmsqosprod.centralus.cloudapp.azure.com
0.0.0.0 pfmsqosprod.southcentralus.cloudapp.azure.com
# 0.0.0.0 pfmsqosprod.westus.cloudapp.azure.com
0.0.0.0 pfmsqosprod.northeurope.cloudapp.azure.com
0.0.0.0 pfmsqosprod.westeurope.cloudapp.azure.com
0.0.0.0 pfmsqosprod.eastasia.cloudapp.azure.com
0.0.0.0 pfmsqosprod.southeastasia.cloudapp.azure.com
0.0.0.0 pfmsqosprod.japanwest.cloudapp.azure.com
0.0.0.0 pfmsqosprod.japaneast.cloudapp.azure.com
0.0.0.0 pfmsqosprod.australiaeast.cloudapp.azure.com
0.0.0.0 pfmsqosprod.australiasoutheast.cloudapp.azure.com
0.0.0.0 pfmsqosprod2.australiasoutheast.cloudapp.azure.com
0.0.0.0 xblcxplatqos-brs-9-18-2-0.cloudapp.net
0.0.0.0 xblcxplatqos-scus-9-18-2-0.cloudapp.net
0.0.0.0 xblcxplatqos-cus-9-18-2-0.cloudapp.net
0.0.0.0 xblcxplatqos-eus-9-18-2-0.cloudapp.net
0.0.0.0 xblcxplatqos-neu-9-18-2-0.cloudapp.net
0.0.0.0 xblcxplatqos-jae-9-18-2-0.cloudapp.net
0.0.0.0 xblcxplatqos-ause-9-18-2-0.cloudapp.net
0.0.0.0 xblcxplatqos-seas-9-18-2-0.cloudapp.net

歴史

Halo5 を機に Halo のマッチングは P2P 形式から Dedicated Servers を使った方式に変わった。一般的に言って後者のほうがラグくなりにくい[1]ので、Halo5 のマルチプレイヤーの発表動画では当然ドヤられていた。もちろんプレイヤーたちも好意的に捉えていた。Halo3 をやっていたときのオーストラリア、ヨーロッパホストのひどさは忘れられない。

Dedicated Servers を使うようになり、各地域のサーバ単位でプレイヤーを募るため過疎ったサーバではマッチングが難しくなった。

原理

ここからは、なぜこの得体の知れないファイルに得体の知れない文章をコピペし、その一部を消すとマッチングに制限がかかるかを説明する。

hostsファイル

編集したファイルは hosts ファイルと呼ばれホスト名と IP アドレスの対応を記述するテキストファイルである。ホスト名と IP アドレスの対応と聞くと DNS を想起するが、この hosts ファイルは DNS サーバが存在しなかった時代にその役割を担っていた。DNS サーバの登場とともに hosts ファイルはローカルにおける最低限の対応を記述するようになり、DNS より優先してホスト名を解決させる仕様になった。

さて、今回 hosts ファイルにコピペした文の1行を見てみよう。例として東日本サーバを検索したくないときに追記する行を以下に示す。

0.0.0.0 pfmsqosprod.japaneast.cloudapp.azure.com

東日本サーバのホスト名と、それに対応する IP アドレスが示されている。この行を hosts ファイルに書くことで MCC はマッチが行われる東日本サーバの IP アドレスを 0.0.0.0 と解決する。

ちなみにこのホスト名は誰がどうやって調べたものかわからない。

0.0.0.0

0.0.0.0 は宛先としては無効を示す[2]。これにより、MCC は東日本サーバのアドレスを無効と解釈し、検索対象からはずすことになる。もう少し細かく流れを説明する。検索を開始した MCC は各サーバの ping 値を調べるためそれぞれと一旦通信を行う。しかし、DNS に代わって hosts ファイルにより 0.0.0.0 と解決された東日本サーバは宛先無効で応答がない。したがって東日本サーバはマッチングに使えないと MCC で解釈される。このように検索するサーバに制限をかけている。

お遊びとして

0.0.0.0 twitter.com

と書くとキャッシュを参照しない限り Twitter にアクセスできなくなる。

また、0.0.0.0 でなくともその IP にアクセスできなければいいので、ループバックアドレス 127.0.0.1 を対応させてもよい。この hosts ファイルを使ったアクセス禁止の方法について調べると 127.0.0.1 でやっている例もある。Windows では 0.0.0.0 のほうが一瞬でタイムアウトするから早いという情報を見たことがあるが、真偽はわからないのと今回の場合はそこまで差はなかろうと思う。詳しくは[3]を参照。

今後

この方法は OS レイヤーでの操作でソフトウエアレイヤーからは影響を受けない。したがって、この方法が使えなくなることはほぼなさそうに感じる。もちろん、ホスト名をこっそり変えて hosts ファイルへの記述を無効にしたり、0.0.0.0 と解決されたサーバは MCC 側で修正するなどで対策は可能である。しかし、基本はいたちごっこなので確実に回避策が出てくると思う。

また、MCC 公式でのサーバ選択機能実装による平和的解決も考えられる。MCC の開発計画によると選択機能は5月の時点で Backlog から Design Iteration に入り、実装の可能性が出てきた[4]。これが実装されればこのような方法に頼らずとも、極めて簡単に堂々と他のサーバに行けるので期待したい。まあ、Infinite が出るまでに実装されるかはかなり怪しい気がするが。

おまけ

直接 hosts ファイルを編集しない方法として、アプリを使う方法もある[5]。やってることは一緒だが GUI になるので簡単に感じる。リポジトリができるほどみんな苦労してるんだなというのが感じられてよい。

参考

[1] https://www.colocationamerica.com/blog/5-dedicated-server-uses
[2] https://tools.ietf.org/html/rfc6890#section-2.2.2
[3] https://www.howtogeek.com/225487/what-is-the-difference-between-127.0.0.1-and-0.0.0.0/
[4] https://www.halowaypoint.com/en-us/news/mcc-development-update-june-2020
[5] https://github.com/343RuinedHalo/MCC-Server-Block

この記事が気に入ったらサポートをしてみませんか？