Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ソシャゲにおけるサーバとクライアントの決めごと

ソーシャルゲームでのサーバとクライアント間で決めておくことの話

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

ソシャゲにおけるサーバとクライアントの決めごと

  1. 1. ソシャゲにおける サーバとクライアントの 決めごと
  2. 2. 自己紹介 @peto_tn エンジニア Java,Obj-C,C#を経てPHPとか
  3. 3. ソシャゲ 必ずクライアント(アプリ)とサーバの 通信が発生 通信する為には色々と取り決めが必要
  4. 4. 決めること ネットワークプロトコル (HTTP, TCP/UDP) データ形式 (XML, JSON, MessagePack, RPC) ゲーム用プロトコル (ゲーム用通信プロトコル) プロトコルの管理方法 (仕様書, バージョン管理, 共通化保障) セキュリティ (SSL/TLS, 暗号化, 難読化)
  5. 5. 決めること ネットワークプロトコル (HTTP, TCP/UDP) データ形式 (XML, JSON, MessagePack, RPC) ゲーム用プロトコル (ゲーム用通信プロトコル) プロトコルの管理方法 (仕様書, バージョン管理, 共通化保障) セキュリティ (SSL/TLS, 暗号化, 難読化)
  6. 6. ネットワークプロトコル 基本HTTPで片付く リアルタイム通信が必要な場合はUDPを (3G回線遅い) UDPは不正確でいいデータのみに絞る (現状リアルタイムは作ってません)
  7. 7. 決めること ネットワークプロトコル (HTTP, TCP/UDP) データ形式 (XML, JSON, MessagePack, RPC) ゲーム用プロトコル (ゲーム用通信プロトコル) プロトコルの管理方法 (仕様書, バージョン管理, 共通化保障) セキュリティ (SSL/TLS, 暗号化, 難読化)
  8. 8. データ形式 選択肢は色々 XMLか JSONか MessagePackか? RPCという手も? 独自シリアライズ作るか?
  9. 9. データ形式  XML : 肥大化して遅くなりがち  JSON : 可読性よい。割りと小さい  MessagePack : バイナリ。小さく速い  RPC : どうしても使いたかったら  独自シリアライズ : 大変 MessagePackおすすめです
  10. 10. データ形式 <?xml version="1.0" encoding="UTF-8" ?> <user_id>123456</user_id> <name>hogehoge</name> <age>20</age> {"user_id":123456, "name":"hogehoge", "age":20} 83 a7 75 73 65 72 5f 69 64 ce 00 01 e2 40 a4 6e 61 6d 65 a8 68 6f 67 65 68 6f 67 65 a3 61 67 65 14 0a XML 102 byte JSON 51 byte 50%削減 MessagePack 34 byte 67%削減
  11. 11. データ形式 1通信  1リクエスト 1通信  複数リクエスト 一度に複数リクエストの方がよい 実装は複雑になる
  12. 12. データ形式 1通信  1リクエスト Client Server ユーザ情報 リクエスト ユーザ情報 レスポンス フレンド情報 リクエスト フレンド情報 レスポンス
  13. 13. データ形式 1通信  複数リクエスト Client Server ユーザ情報 リクエスト ユーザ情報 レスポンス フレンド情報 リクエスト フレンド情報 レスポンス
  14. 14. 決めること ネットワークプロトコル (HTTP, TCP/UDP) データ形式 (XML, JSON, MessagePack, RPC) ゲーム用プロトコル (ゲーム用通信プロトコル) プロトコルの管理方法 (仕様書, バージョン管理, 共通化保障) セキュリティ (SSL/TLS, 暗号化, 難読化)
  15. 15. ゲーム用プロトコル ユーザID, パスワード, ユーザ名 ゲームで必要なデータを設計 ログイン アイテムID, 使用個数アイテム使用 ユーザID, フレンドIDフレンド申請
  16. 16. ゲーム用プロトコル リクエストとレスポンス フレンド一覧 取得 リクエスト ユーザID レスポンス フレンド一覧
  17. 17. ゲーム用プロトコル 共通の定数 フレンド状態 0: フレンド未登録 1: フレンド申請中 2: フレンド登録済
  18. 18. ゲーム用プロトコル 全レスポンスの共通項目 リクエストの成否/エラー情報 メンテナンス情報 通信エラー コード1000 OK メンテナンス中 OK
  19. 19. 決めること ネットワークプロトコル (HTTP, TCP/UDP) データ形式 (XML, JSON, MessagePack, RPC) ゲーム用プロトコル (ゲーム用の通信プロトコル) プロトコルの管理方法 (仕様書, バージョン管理, 共通化保障) セキュリティ (SSL/TLS, 暗号化, 難読化)
  20. 20. プロトコルの管理方法 クライアント/サーバで共有し参照する 資料 Excel, SpreadSheet etc. 概要 コマンド名 リクエスト レスポンス ログイン login int: user_id string: password int: result
  21. 21. プロトコルの管理方法 Client Server userid : 1234 password : hoge user_id が送られて 来ていない! ログインする からデータ 送るよ
  22. 22. プロトコルの管理方法 サーバ/クライアント両方に対して 確実にデータ構造を保障したい
  23. 23. 共通の定義を記述し、サーバ用、クライ アント用に自動コンバート/反映させる プロトコルの管理方法 プロトコル サーバ クライアント
  24. 24. プロトコルのコンバート プロトコルの管理方法 { “request”: { “user_id”: {“type”: “int”, “comment”: “ユーザーID"} }, "response": { "result": {"type": "int", "comment": "結果"} } } public class UserReq { public int userId; } public class UserRes { public int result; } public class MessageUserRequest { public int UserId { get; set; } } public class MessageUserResponse { public override int Result { get; set; } }
  25. 25. 定数のコンバート プロトコルの管理方法 STATE_SEND_REQUEST,0,,フレンド未登録, STATE_RECV_REQUEST,1,,申請中, STATE_ACCEPTED,2,,フレンド登録済, public final class ConstFriend { public static final int STATE_SEND_REQUEST = 0; public static final int STATE_RECV_REQUEST = 1; public static final int STATE_ACCEPTED = 2; } public static class ConstFriend { public const int STATE_SEND_REQUEST = 0; public const int STATE_RECV_REQUEST = 1; public const int STATE_ACCEPTED = 2; }
  26. 26. マスタのコンバート プロトコルの管理方法 id name rarity type 1 ゴブリン 1 1 2 ドラゴン 2 2 INSERT INTO `data_monsters` (`id`, `name`, `rarity`, `type`) VALUES (1, ‘ゴブリン’, 1, 1), (2, ‘ドラゴン’, 2, 2); 1,ゴブリン,1,1 2,ドラゴン,2,2 DB 配信用 アセット
  27. 27. プロトコルの管理方法 クライアントとサーバのソースは 同一リポジトリに置いたほうが楽 リポジトリが肥大化してやばいなら、 別途安全な反映方法を検討する必要あり プロトコルもバージョン管理へ
  28. 28. 決めること ネットワークプロトコル (HTTP, TCP/UDP) データ形式 (XML, JSON, MessagePack, RPC) ゲーム用プロトコル (ゲーム用の通信プロトコル) プロトコルの管理方法 (仕様書, バージョン管理, 共通化保障) セキュリティ (SSL/TLS, 暗号化, 難読化)
  29. 29. セキュリティ 全ての通信に暗号化、難読化 アカウント、課金周りは細心の注意を! SSL/TLS、各種暗号化 それでも不正はある 不正対策は十分行う
  30. 30. その他 アセットの配布方法 セッションの保持方法 などなど
  31. 31. 最後に 色々ちゃんと決めとかないと死ぬ 変な決め方をしても死ぬ ゲームにあった最適なものを採用!
  32. 32. ありがとうございました

    Be the first to comment

    Login to see the comments

  • ssuser91ce3e

    Jul. 7, 2016
  • yukiakiya

    Oct. 1, 2019

ソーシャルゲームでのサーバとクライアント間で決めておくことの話

Views

Total views

3,532

On Slideshare

0

From embeds

0

Number of embeds

1,040

Actions

Downloads

10

Shares

0

Comments

0

Likes

2

×