/KCVDB

Primary LanguageC#

KCVDB

Build status

送信プロトコル仕様

検証DBには以下の情報を送信する。

  • SessionId セッションを表すUUID文字列。セッションについては後述。
  • AgentId 送信クライアントとそのバージョンを表す文字列。
  • RequestUri 艦これAPIの絶対URL。スキーマ(http)、ホスト(IPアドレスまたはドメイン)も含める。
  • RequestBody 艦これAPIのリクエストボディ。
  • ResponseBody 艦これAPIのレスポンスボディ。なお、svdata=等のプレフィックスも削除せずそのまま与える。
  • StatusCode 艦これAPIのレスポンスのステータスコードを表す数値。
  • HttpDate 艦これAPIのレスポンスヘッダーのDateフィールドから得られる文字列。
  • LocalTime 送信クライアントが艦これAPIを受信した日時を表すRFC1123形式の文字列。

プロトコルには以下の三種類がある

  • /api/send/gzip
  • /api/send/multi
  • /api/send

/api/send/gzip

https://kancollevdataapi.azurewebsites.net/api/send/gzipmultipart/form-dataでPOSTする。検証DBへの送信が完了するまで、次の艦これAPIを送信してはならない。

multipart/form-dataで指定する引数は以下の通り。

metadata 以下に示すJSON文字列

{
 "SessionId": "",
 "AgentId": ""
}

body 以下に示すJSON文字列gzip圧縮したバイナリデータ。JSONの配列内には送信する艦これAPIを、艦これサーバーから受信した順番に格納する。

[
 {
  "RequestUri": "",
  "RequestBody": "",
  "ResponseBody": "",
  "StatusCode": ,
  "HttpDate": "",
  "LocalTime": "",
 }
]

検証DBへの負荷軽減のため、未送信の艦これAPIが2つ以上ある場合、それらを1回の送信でまとめておくるべきである。例えば、検証DBへ艦これAPIを送信している間に艦これサーバーから新しい艦これAPIを2つ以上受信した場合、それらをまとめて一度に検証DBへ送信するのが望ましい。

/api/send/multi

工事中

/api/send

工事中

セッション

セッションとは、艦これのAPIが連続していることを保証するためのものである。例として、母港更新→秘書艦を赤城から長門に変更→開発という順で操作した場合で説明する。このとき、提督があらかじめ送信クライアントを立ち上げて起き、母港更新後に送信クライアントを終了し、開発する前に再度送信クライアントを立ち上げた場合に問題がおきる。この場合、送信クライアントは母港更新と開発のAPIだけを受け取り、秘書艦変更のAPIは受け取れない。何も対策をしなかった場合、実際には秘書艦変更後の長門で開発を行ったにもかかわらず、検証DBからは秘書艦変更前の赤城で開発を行ったように見えてしまう。このような事態を防ぐために導入されたのがセッションである。送信クライアントは艦これAPIと共にセッションIDを表すUUID文字列を送信する。送信クライアントは、このセッションIDが等しいAPI同士で、その間にAPIの欠損がなく連続していることを保証しなければならない。先の例の場合は、母港更新のAPIと開発のAPIとでセッションIDに異なるものを指定することで、開発結果を秘書艦不明として処理することができる。

セッションIDはUUID version 4で生成された一意の文字列である。送信クライアントは以下の場合にこれまでのセッションIDを破棄し、新しい一意のセッションIDを再生成しなければならない。

  • 送信クライアントが検証DBへの送信を開始したとき。
  • 送信クライアントが艦これFlashとプロキシ接続を開始したとき。
  • 送信クライアントが受信した艦これAPIを、検証DBへの送信失敗したなどの理由で送信しないまま破棄した場合。

UUID文字列はxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxという形式とする。アルファベットは小文字で、{}では囲まない。

HttpDateとLocalTime

HttpDateは艦これサーバーが艦これAPIを送信した日時、LocalTimeは送信クライアントが艦これAPIを受信した日時として区別し、両方送信する仕様となっている。

送信失敗時の処理

検証DBへの送信に失敗した場合は、以下の2つの中からどちらかの処理を選ぶ。なお送信に失敗するとは、検証DBからレスポンスが得られなかった場合か、またはレスポンスは得られたがステータスコードが200以外の場合を指す。

  1. 送信に失敗した艦これAPIを破棄し、セッションIDを再生成する。
  2. 一定時間待機したのち、未送信の艦これAPIを再送する。待機している間に新たに艦これサーバーから受信した場合は、そのデータも加えた上で再送するべきである。待機時間は、最初に失敗した場合は1秒以上あける。連続で失敗した場合は、直前の待機時間に20秒以上加えた時間をあける。つまり、最初に送信に失敗した場合は1秒以上、2回連続で失敗した場合は21秒以上、3回連続で失敗した場合は41秒以上のようになる。