etc

Dose Not Existの対策と原因を考える(2013/6/27版)

Amazonのアソシエイトとして、8796.jp管理日誌は適格販売により収入を得ています。

25日の夜以降なんかしらんけどバースターは使えないしリサイクルもできないしなんだこりゃ

原因は後で時間のあるときに書くとして、取り急ぎ対策

 

全部 Drop して拾いなおせ

以上

Drop はアイテム開いてこれ

image

途中で Dose Not Exist が出て Drop してもアイテム数減らなくなったら DEVICE → Force sync するとそのアイテムが消えるので続けて Drop Drop Drop …

「L1 Resonator」を全部落とせたら拾いなおして、「L2 Resonator」を全部落とせたら拾い直して…(繰り返し)みたいにアイテムの種類ごとに全部落としてから拾い直すようにしましょう(理由は後述)。

Force sync の場所はここ

image

アプリの管理からキャッシュのクリアは多分必要ないかなと思ってます。

注意点としては

  • 1種類全部落とし終わってから拾うように
  • 誰かに拾われないような場所でやれ
  • 回線は速くて安定してるほうがいい
  • Force sync してすぐアイテム一覧見てめっちゃ数が減ってても慌てない

発生した原因とか裏側のデータベース的なものの考え方とか言いたいことはあるんだけど時間がないのでまたあとで。

つづき。

ここからは推論で「アイテム管理どうなってんの」と「なぜこんなことになったか」ってのをてきとうに

全部推論なので、「たぶん。きっと。気がする。おそらく。」連発してます。

アイテム管理どうなってんの?

以前 Portal Shield の硬さに変更が入った時に、「新規で取得したアイテムには新しい数値が適用されてるのに在庫を設置した場合は古い数値が適用される」という話がありました。

つまり、アイテム管理は「[Portal Shield COMMON]というアイテムを10個持ってる」ではなく、「それぞれ固有 ID とステータスを持った[Portal Shield COMMON] を10種類持っている」らしいと推察できます。

そりゃそうですよね。ネトゲとしては正しいアイテム管理だと思います。

固有 ID なのでアイテム増殖というチートはできませんよと。

数千人数万人が同時にアイテム使ってちゃんと処理できるのかどうかっていうのは別のお話。Google App Engine のパワーの見せ所なのかー?

 

で、入手した新しいアイテムから使う傾向があるような気がしますが、それはイマイチわかってません。

今回 L7 Resonator を手持ち全部捨ててみたんですが、100個捨てる途中で何度か Drop に失敗して95個目ぐらいでもエラーがでたので、同一アイテムは「全部捨ててから拾い直す」のが重要です。途中で拾い直しちゃったら意味がありません。別に Resonator 全部捨ててから拾いなおす必要はありません。レベルが違うアイテムは別のアイテムなので混在することはないです。

 

なぜこんなことになった?

原因はおそらく日本時間6/25夜に発生してた Google App Engine の障害です。

Google App Engine HR Datastore Status

データベースが巻き戻ったとかいう情報もどっかでみました

たぶん、端末に所有アイテム一覧を送るデータは大元のアイテムデータベースから独立したキャッシュのようなもので、ログインや Force sync 時に端末に一覧を送る処理を高速化しています。たぶん22日から変更されてる気がする。

で、大元のアイテムデータベースと端末送るためのキャッシュと不整合が起きている結果が Dose Not Exist ですね。

大元ではもう使ったことになってる[固有ID]のアイテムが使われたらそりゃ「そんなアイテムねーよw」って返しますよね。チート対策としては正しい挙動です。

処理の流れとしては

  1. 端末上でアプリ起動してデータよこせ要求
  2. キャッシュサーバーがアイテム一覧を送信(すでに使用済みの ID も含む)
  3. 端末が受信(すでに使用済みの ID も含む)
  4. 端末上ですでに使用済みの ID を使おうとする
  5. アイテムサーバーが「Dose Not Exist」を返す→キャッシュサーバーにその ID を削除指示
  6. 端末「なんかしらんけどエラーで使えなかった」(すでに使用済みの ID を持ち続ける)
  7. エージェント「なんかしらんけどエラーでたしw また使うかwww」
  8. アイテムサーバーが「Dose Not Exist」を返す→キャッシュサーバーにその ID を削除指示(もう消えてる)
  9. (繰り返し)

ってなってると思います。

5の時点でキャッシュサーバーからその ID は削除されてるので Force sync すればそれが除外されたアイテム一覧が取得出来ます。

ちなみにポータルの Upgrade で「WRONG_ITEM_TYPE」が出るのはアイテムサーバーにその ID がないので、その ITEM_TYPE がおそらく NULL 的なもので返されて「そんな種類知らんがな」って言ってるものと思われるので上記と同じ現象です。

事象が発生する人としない人がいるのは障害発生前後にアイテム増減に係る動作をしたかしてないかってだけだと思います。たぶん。

 

なので、ユーザー側でできる対策は「全部 Drop して拾いなおせ」ということですね。

運営が大元のアイテムデータベースからキャッシュを再構築してくれれば解決すると思いますがね。

 

ああ、そうそう。「8796m」ってコードネームのエージェントはぼくとは無関係で、作った人曰く「旦那への嫌がらせのために作成した」そうです。困ったもんですね!

コメント

タイトルとURLをコピーしました