コンテンツにスキップ

利用停止通知ゲームサーバー登録

利用停止ユーザー情報を新規登録または変更する場合、または利用停止を解除する場合に、該当データをゲームサーバーへリアルタイムで自動送信するAPIです。ゲームサーバーはこのAPIを通じてユーザーの利用停止状態の変化を即時に受信し、サービスに反映します。

  • データ伝達タイミング: 利用停止ユーザーの情報が新規登録または変更されたとき、および利用停止が解除されたときに、自動でゲームサーバーへ伝達されます。利用停止解除には、管理者が直接解除した場合と利用停止期間が満了した場合の両方が含まれ、どちらの場合もstatusEで伝達されます。
  • データ送信単位: 1回のリクエスト(Request)で最大100件の利用停止ユーザー情報が送信されます。ただし、同一ユーザーの処理順序を保証するためにユーザーを複数のグループに分けて送信するため、対象が多い場合でも常に100件ずつ送信されるとは限りません。リクエスト数と1リクエストあたりの件数は、対象ユーザーの分布によって異なります。

このAPIを使用するには、リクエスト(Request)を受け取れるようにゲームサーバーを準備した後、Hiveコンソール > 認証 > 利用停止 > ゲームサーバー登録でゲームサーバーを登録する必要があります。

ゲームサーバー実装時の注意事項
  • 重複受信への対応(冪等性の保証): ネットワーク送信に失敗すると再試行(Retry)ロジックが動作するため、同じイベントデータを2回以上受信することがあります。ゲームサーバーは、同じリクエストを複数回受信してもシステム状態が一貫して維持されるよう、冪等(Idempotent)に処理する必要があります。
  • 順序逆転の可能性: 送信に失敗したリクエストは再送信キューに格納されて後から送信される一方で、後続のリクエストは待機せず先に送信される場合があります。そのため、同一ユーザーに対して「登録 -> 変更 -> 解除」イベントが短時間に連続して発生すると、リクエストの到着順序が入れ替わることがあります。
  • 最新状態の判定(event_time比較): リクエストの到着順序が実際のイベント発生順序と異なる場合があるため、受信データをゲームサーバーに適用する前に必ずevent_timeフィールドを比較し、最新状態かどうかを判定してから処理してください。詳しいロジックは処理順序を判定するを参照してください。
  • ゲームサーバー状態確認は必須: 利用停止ユーザー情報とは別に、ゲームサーバーが受信可能な状態かを確認する状態確認リクエストが定期的に送信されます。このリクエストに正常応答しない場合、イベント伝達が停止されるため、ゲームサーバー状態確認ガイドを必ず確認して処理してください。


リクエストURL

Request URL Hiveコンソールに登録したプロジェクトのゲームサーバーURL([認証 > 利用停止 > ゲームサーバー登録])
HTTP Method POST
Content-Type application/json
Data Format JSON


リクエストヘッダー

フィールド名 説明 タイプ 必須
Authorization ゲームサーバー認証用のBearerトークン
Bearer {ゲームサーバー認証キー}形式で伝達されます。
String Y
Note
  • ゲームサーバー認証キーは、Hiveコンソール[認証 > 利用停止 > ゲームサーバー登録 > プロジェクト詳細 > ゲームサーバー認証キー]で確認できます。
  • ゲームサーバー認証キーの検証は、リクエストを受信するゲームサーバーで直接実装する必要があります。


リクエスト本文

フィールド名 説明 タイプ 必須
game_index ゲームインデックス Integer Y
server_url ゲームサーバーURL String Y
data 利用停止ユーザー一覧(最大100件) List Y
data[].event_time 発行時刻(epochミリ秒)
ゲームサーバーが処理順序を判定する値です。詳細
Long Y
data[].player_id Player ID Integer Y
data[].status 利用停止状態
  • P: 永久利用停止ユーザー
  • B: 利用停止期間がある利用停止ユーザー
  • E: 利用停止解除
String Y
data[].start_date 利用停止開始日
statusEの場合、解除された利用停止の開始日が伝達されます。
String Y
data[].end_date 利用停止終了日
statusEの場合、解除された利用停止の終了日が伝達されます。
String Y


リクエスト例

1回のリクエストに含まれるdataは、すべて同じstatusと同じevent_timeを持ちます。異なる状態が1つのリクエストに混在して伝達されることはありません。

期間付き利用停止(B

{
  "game_index": 539,
  "server_url": "{Hiveコンソールに登録したプロジェクトのゲームサーバーURL}",
  "data": [
    {
      "event_time": 1720612623847,
      "player_id": 1,
      "status": "B",
      "start_date": "2024-07-10 20:56:59",
      "end_date": "2024-07-13 20:56:59"
    },
    {
      "event_time": 1720612623847,
      "player_id": 2,
      "status": "B",
      "start_date": "2024-07-10 20:56:59",
      "end_date": "2024-07-13 20:56:59"
    }
  ]
}

永久利用停止(P

{
  "game_index": 539,
  "server_url": "{Hiveコンソールに登録したプロジェクトのゲームサーバーURL}",
  "data": [
    {
      "event_time": 1720612624215,
      "player_id": 3,
      "status": "P",
      "start_date": "2024-07-10 20:56:59",
      "end_date": "9999-12-31 00:00:00"
    },
    {
      "event_time": 1720612624215,
      "player_id": 4,
      "status": "P",
      "start_date": "2024-07-10 20:56:59",
      "end_date": "9999-12-31 00:00:00"
    }
  ]
}

利用停止解除(E

解除された利用停止の期間がそのまま伝達されるため、start_dateend_dateはユーザーごとに異なる場合があります。

{
  "game_index": 539,
  "server_url": "{Hiveコンソールに登録したプロジェクトのゲームサーバーURL}",
  "data": [
    {
      "event_time": 1720829722391,
      "player_id": 5,
      "status": "E",
      "start_date": "2024-07-01 10:00:00",
      "end_date": "2024-07-08 10:00:00"
    },
    {
      "event_time": 1720829722391,
      "player_id": 6,
      "status": "E",
      "start_date": "2024-07-03 15:30:00",
      "end_date": "9999-12-31 00:00:00"
    }
  ]
}


処理順序を判定する

event_timeは、Hiveサーバーが該当情報を発行した時刻をepochミリ秒(1970年1月1日 00:00:00 UTCから経過したミリ秒)で表した値です。たとえば1720612623847はKST基準で2024-07-10 20:57:03.847です。値が大きいほど後に発生した処理であるため、ゲームサーバーはこの値を比較することで、リクエストの到着順序に関係なく最新状態を判定できます。

player_idごとに最後に反映したevent_timeを保存しておき、新しく受信した値と比較して以下のように処理してください。

比較結果 意味 処理
受信した値 > 保存した値 より後に発生した処理 反映し、保存した値を更新
受信した値 = 保存した値 すでに反映済みの処理の再送信 無視(または冪等に再反映)
受信した値 < 保存した値 遅れて到着した過去の処理 無視
event_time使用時の注意事項
  • 比較は**同じplayer_idのユーザー同士でのみ**実行してください。異なるユーザーが同じevent_timeを持つ場合があるため、ユーザーを区別せずに比較すると、正常なリクエストを過去の処理と誤認して漏れが発生する可能性があります。
  • 再送信されたリクエストは初回発行時刻をそのまま維持します。再送信であっても値は更新されないため、遅れて到着した過去のリクエストをこの値で除外できます。
  • event_timeはHiveサーバーが発行した時刻であり、ゲームサーバーの受信時刻やstart_dateend_dateとは異なる値です。順序判定にはstart_dateではなくevent_timeを使用してください。
  • event_timeはタイムゾーンに依存しない絶対時刻です。ゲームサーバーとHiveサーバーのタイムゾーンが異なっていても、順序判定結果は変わりません。

受信した値が最新状態かどうかを確実に確認する必要がある場合は、ゲーム利用停止ユーザーを確認するAPIで該当ユーザーの現在状態を照会してください。


レスポンス本文

ゲームサーバーはリクエストを正常に処理した後、以下の形式で応答する必要があります。

フィールド名 説明 タイプ
result_code レスポンスコード 詳細 Integer

レスポンスコード

コード値 説明
0 成功
その他 失敗(ゲームサーバーで定義したエラーコード)


レスポンス例

成功

{
  "result_code": 0
}


ゲームサーバー状態確認

登録されたゲームサーバーが利用停止ユーザー情報を受信できる状態か確認するため、一定の間隔で状態確認リクエストを送信します。リクエストURL、リクエストヘッダー、リクエスト本文の形式は、実際の利用停止ユーザー情報伝達と同じです。

送信間隔は運用状況に応じて調整される場合があります。そのため、ゲームサーバーは特定の周期を前提として実装してはいけません。リクエストを受信した時点に関係なく、常に正常応答を返せる必要があります。

状態確認リクエストのdataフィールドには、以下のようにplayer_id1のダミーデータ1件のみが含まれて伝達されます。

  • player_id: 1(実際には存在しないダミーID)
  • event_time / start_date: 状態確認リクエストを送信した時刻
  • 例外処理必須: player_id1のリクエストは、受信可否だけを確認するためのシグナルです。実際の利用停止ロジックを実行してはならず、処理順序判定の対象からも除外する必要があります。
{
  "game_index": 539,
  "server_url": "{Hiveコンソールに登録したプロジェクトのゲームサーバーURL}",
  "data": [
    {
      "event_time": 1720612623847,
      "player_id": 1,
      "status": "P",
      "start_date": "2024-07-10 20:57:03",
      "end_date": "9999-12-31 00:00:00"
    }
  ]
}

ゲームサーバーは状態確認リクエストにもresult_codeを含むレスポンスを返す必要があります。result_codeの値は確認せず、フィールドが存在するかのみを確認するため、存在しないユーザーと判断して失敗コード(0以外の値)を返しても正常応答として処理されます。

状態確認に失敗すると利用停止ユーザー情報の伝達が停止されます

応答がない、またはresult_codeがない応答が連続して5回発生すると、該当ゲームサーバーは使用不可状態に切り替わり、その時点から実際の利用停止ユーザー情報は伝達されません。その後、状態確認リクエストに正常応答すると使用可能状態に自動復旧し、再び伝達されます。

したがって、player_id1のリクエストを別途フィルタリングせず、実際のリクエストと同じ経路で処理し、常にresult_codeを含むレスポンスを返すように実装してください。