이용 정지 알림 게임 서버 등록¶
이용 정지 사용자 정보를 신규 등록하거나 변경하거나 제재를 해제할 때 해당 데이터를 게임 서버로 실시간 자동 발송하는 API입니다. 게임 서버는 이 API를 통해 사용자의 제재 상태 변화를 즉시 수신하여 서비스에 반영합니다.
- 데이터 전달 시점: 이용 정지 사용자의 정보가 새로 등록되거나 변경될 때, 그리고 이용 정지가 해제될 때 자동으로 게임 서버로 전달됩니다. 이용 정지 해제는 관리자가 직접 해제한 경우와 이용 정지 기간이 만료된 경우를 모두 포함하며, 두 경우 모두
status가E로 전달됩니다. - 데이터 전송 단위: 한 번의 요청(Request)으로 최대 100건의 이용 정지 사용자 정보가 전송됩니다. 다만 동일한 사용자의 처리 순서를 보장하기 위해 사용자를 여러 그룹으로 나누어 전송하므로, 대상이 많더라도 항상 100건을 채워서 전송되지는 않습니다. 요청 횟수와 요청당 건수는 대상 사용자의 분포에 따라 달라집니다.
이 API를 사용하려면 요청(Request)을 받을 수 있도록 게임 서버를 준비한 후, Hive 콘솔 > 인증 > 이용 정지 > 게임 서버 등록에서 게임 서버를 등록해야 합니다.
게임 서버 구현 시 유의사항
- 중복 수신 대비 (멱등성 보장): 네트워크 전송 실패 시 재시도(Retry) 로직이 작동하므로 동일한 이벤트 데이터를 두 번 이상 수신할 수 있습니다. 게임 서버는 동일 요청이 여러 번 들어와도 시스템 상태가 일관되게 유지되도록 멱등(Idempotent)하게 처리해야 합니다.
- 순서 역전 가능성: 전송에 실패한 요청은 재전송 대기열에 적재되어 나중에 발송되는 동안, 후속 요청은 대기 없이 먼저 전송될 수 있습니다. 따라서 동일 사용자에 대해 '등록 → 변경 → 해제' 이벤트가 단시간에 연달아 발생할 경우 요청 도착 순서가 뒤바뀔 수 있습니다.
- 최신 상태 판별 (
event_time비교): 요청이 도착한 순서가 실제 이벤트 발생 순서와 다를 수 있으므로, 수신 데이터를 게임 서버에 적용하기 전에 반드시event_time필드를 비교해 최신 상태인지 판별한 후 처리하세요. 자세한 로직은 처리 순서 판별하기를 참고하세요. - 게임 서버 상태 확인 필수: 이용 정지 사용자 정보와 별개로, 게임 서버의 수신 가능 상태를 확인하는 상태 확인 요청이 주기적으로 전송됩니다. 이 요청에 정상 응답하지 않으면 이벤트 전달이 중단되므로 게임 서버 상태 확인 가이드를 반드시 확인하여 처리하세요.
Request URL¶
| Request URL | Hive 콘솔에 등록한 프로젝트의 게임 서버 URL ([인증 > 이용 정지 > 게임 서버 등록]) |
|---|---|
| HTTP Method | POST |
| Content-Type | application/json |
| Data Format | JSON |
Request header¶
| 필드명 | 설명 | 타입 | 필수 여부 |
|---|---|---|---|
| Authorization | 게임 서버 인증을 위한 Bearer 토큰Bearer {게임 서버 인증키} 형식으로 전달됩니다. | String | Y |
Note
- 게임 서버 인증키는 Hive 콘솔 [인증 > 이용 정지 > 게임 서버 등록 > 프로젝트 상세 > 게임 서버 인증키]에서 확인할 수 있습니다.
- 게임 서버 인증키 검증은 요청을 받는 게임 서버에서 직접 구현해야 합니다.
Request body¶
| 필드명 | 설명 | 타입 | 필수 여부 |
|---|---|---|---|
| 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 | 이용 정지 상태
| String | Y |
| data[].start_date | 이용 정지 시작일status가 E이면 해제된 이용 정지의 시작일이 전달됩니다. | String | Y |
| data[].end_date | 이용 정지 종료일status가 E이면 해제된 이용 정지의 종료일이 전달됩니다. | String | Y |
Request example¶
한 번의 요청에 담기는 data는 모두 같은 status와 같은 event_time을 가집니다. 서로 다른 상태가 한 요청에 섞여서 전달되지 않습니다.
기간 이용 정지 (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_date와 end_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_date·end_date와는 다른 값입니다. 순서 판별에는start_date가 아닌event_time을 사용하세요.event_time은 타임존과 무관한 절대 시각입니다. 게임 서버와 Hive 서버의 타임존이 달라도 순서 판별 결과는 바뀌지 않습니다.
수신한 값이 최신 상태인지 확실히 확인해야 한다면 게임 이용 정지 사용자 확인하기 API로 해당 사용자의 현재 상태를 조회하세요.
Response body¶
게임 서버는 요청을 정상적으로 처리한 후 아래 형식으로 응답해야 합니다.
| 필드명 | 설명 | 타입 |
|---|---|---|
| result_code | 응답 코드 자세히 | Integer |
응답 코드¶
| 코드값 | 설명 |
|---|---|
| 0 | 성공 |
| 그 외 | 실패 (게임 서버에서 정의한 에러 코드) |
Response example¶
성공¶
게임 서버 상태 확인¶
등록된 게임 서버가 이용 정지 사용자 정보를 수신할 수 있는 상태인지 확인하기 위해 일정한 간격으로 상태 확인 요청을 전송합니다. 요청 URL과 요청 헤더, 요청 본문의 형식은 실제 이용 정지 사용자 정보 전달과 동일합니다.
전송 간격은 운영 상황에 따라 조정될 수 있습니다. 따라서 게임 서버가 특정 주기를 가정하고 구현해서는 안 됩니다. 요청 수신 시점과 관계없이 항상 정상 응답을 반환할 수 있어야 합니다.
상태 확인 요청의 data 필드에는 아래와 같이 player_id가 1인 더미 데이터 한 건만 포함되어 전달됩니다.
player_id:1(실제 존재하지 않는 더미 ID)event_time/start_date: 상태 확인 요청을 발송한 시각- 예외 처리 필수:
player_id가1인 요청은 수신 가능 여부만 확인하기 위한 신호입니다. 실제 이용 정지 로직을 수행하지 않아야 하며, 처리 순서 판별 대상에서도 제외해야 합니다.
{
"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_id가 1인 요청을 별도로 걸러내지 말고, 실제 요청과 동일한 경로로 처리해 항상 result_code를 포함한 응답을 반환하도록 구현하세요.