Contenu connexe Similaire à CEDEC 2015 IoT向け汎用protocol MQTTのリアルタイムゲーム通信利用と実装、そして未来へ… (20) Plus de Drecom Co., Ltd. (20) CEDEC 2015 IoT向け汎用protocol MQTTのリアルタイムゲーム通信利用と実装、そして未来へ…1. Copyright Drecom Co., Ltd. All Rights Reserved.
1
IoT向け汎用protocol MQTTの
リアルタイムゲーム通信利用と実装、
そして未来へ…
株式会社ドリコム
川上知成
市川毅明
2. Copyright Drecom Co., Ltd. All Rights Reserved.
2
講演者紹介
テクノロジー本部 研究開発部長
• 川上 知成
– 技術調査
– PM ・TD レビュー
同部
• 市川 毅明
– アーキテクト
– ゲーム・汎用基盤開発
3. Copyright Drecom Co., Ltd. All Rights Reserved.
3
本セッションの概要
• 弊社 崖っぷちバスターズ®でリアルタイム
通信4人協力バトルの実現に、MQTT
protocolを採用
• インターネット時代における通信技術の
トレンドとともに採用に至った選定過程、
クライアント/サーバー実装やインフラ
構成などを紹介
受講者が得られるであろう知見:
• 技術採用プロセス事例
• リアルタイム通信
ゲームクライアント・サーバー開発技術・手法
• OSS技術の活用方法
4. Copyright Drecom Co., Ltd. All Rights Reserved.
4
目次
1. ネットワークゲームの近年の流れについて
2. インターネットモバイルリアルタイム
ゲームを実現する課題
3. 弊社事例:崖っぷちバスターズ®
1. 通信技術選定
2. MQTTとは
3. 実装について
1. 全体概略
2. サーバー実装概略
3. アプリケーション実装
4. 考察
5. そして未来へ…
6. Copyright Drecom Co., Ltd. All Rights Reserved.
6
IoT
=Internet of Things
IoT
背景
デバイスの進化
ネットワーク技術の進化
ゲーム
スマートフォン
クラウド上での運営
8. Copyright Drecom Co., Ltd. All Rights Reserved.
8
ネットワークゲーム
• 2000年前後
– アーケード:店舗間専用線
– パソコン通信、インターネット
– MO/MMORPGの誕生
• 2010年頃以降
– 高速インターネット環境 Gbps
– MO/MMORPGの普及と多様化
– eSports 誕生
– モバイルゲームの一般化
9. Copyright Drecom Co., Ltd. All Rights Reserved.
9
モバイルの潮流
• 通信環境:
– 従量課金
– パケット定額
– ブロードバンド普及
wifi通信の利用促進
– 3G/4Gの誕生
→常時接続通信が可能に
• 携帯モバイルゲーム
– カジュアル・ミニゲーム
– webソーシャルゲーム
– Nativeソーシャルゲーム
→携帯モバイルゲームの一般化
常時通信×携帯モバイルゲームが進化
→リアルタイム体感へ
12. Copyright Drecom Co., Ltd. All Rights Reserved.
12
通信環境
• 回線速度
業務用∼家庭用∼移動通信(3G/4GLTE)
例:10Gbps超∼数G - 100MB∼70- 20 MB
– 理論値と実測値
– 不安定
• 帯域保証
• 物理的な干渉・回折
• 移動体通信網とWifiの混在
→転送頻度/データ量の考慮
13. Copyright Drecom Co., Ltd. All Rights Reserved.
13
実装手法
• protocol:
リアルタイム通信の特殊性
– UDP / TCPなど通信protocol の選択/設計
– Data Format / Payload 設計
• 実装効率:
ゲームという専門性ó汎用性
– 設計はゲームロジックによるアプリ毎様々
14. Copyright Drecom Co., Ltd. All Rights Reserved.
14
インフラ環境
• インフラ環境の変化:
– 専用線+オンプレミス
– インターネット+オンプレミス
– インターネット+IaaS/Paasクラウド
• 技術課題
– Load Balancing
– NAT超え
– 爆発的なユーザ増加に合わせた受け入れ
→可用性・冗長性
16. Copyright Drecom Co., Ltd. All Rights Reserved.
16
崖っぷちバスターズ® ご紹介
崖っぷちバスターズ®は、壁を壊して、敵を崖から突き落す、新感覚のぶっ
放し協力バトルゲームです。GPS連動したエリアバトルでスコアランキング
を競い、エリアNo.1になることで、そのエリアを制圧しながら拡大していくこ
とができます。また、最大4人で遊べるマルチプレイ機能を搭載!仲間と連
携して必殺技を繰り出せば、敵に大ダメージを与えることができます。手に
汗握るバトルが繰り広げられる、「みんなで遊べるゲーム」の決定版です。
17. Copyright Drecom Co., Ltd. All Rights Reserved.
17
ゲームの特徴 <通信>
• シングルプレイ
– Web API通信を中心に構成
– バトルはスタンドアローン
• マルチプレイ
– バトルはリアルタイム通信を行い、
最大4名の複数プレイヤーが1つの
バトルセッションで協力プレイ
18. Copyright Drecom Co., Ltd. All Rights Reserved.
18
開発基盤Bisque
Bisqueにて開発
Copyright Drecom Co., Ltd. All Rights Reserved. 28
Bisque!
Bisque !
JNIObjecGve'C++!
20. Copyright Drecom Co., Ltd. All Rights Reserved.
20
通信技術選定の背景
弊社観点
• 強み
– WebAPIを中心のサーバー/クライアント資産
– クラウド利用実績
• 弱み
– リアルタイムサーバー・クライアント構築
– リアルタイム通信ゲーム制作
21. Copyright Drecom Co., Ltd. All Rights Reserved.
21
リアルタイム通信 実現に向けて
⃝方針
– 実現スピード重視
既存技術を活用し、工期短縮
– ゲーム仕様実現に焦点
⃝ゲーム仕様
– 1Room 4名のターン制
⃝技術要件
– リアルタイム性→同期通信
– 同期性の担保 レイテンシー:最大1秒目標
クライアントにHostを立て、
サーバはメッセージの同期のみ
クライアント側ではメッセージを元に再現
プロトを経て
23. Copyright Drecom Co., Ltd. All Rights Reserved.
23
技術検討の一部
• http polling
• websocket
• Socket.io
• MQTT
• Platform機能
• 商用エンジン
• 選定観点
– Protocol
– Server実装
– Client実装
– ライセンス
総合的に評価
MQTT案ベースに詳細検討
24. Copyright Drecom Co., Ltd. All Rights Reserved.
24
Client
検証フェーズ
検証 仮実装 本実装 結合 β
■MQTT案
Game
イ
ン
フ
ラ
ミドルウェア選定
単体負荷試験
クラウド選定
構成設計
ブラッシュアップ
実データ負荷テスト
組み込みテスト
α→機能洗い出し
仕様検証
基本ライブラリ選定
ライブラリ実装 チューニング
単体検証
仕様ブラッシュアップ
組み込み実装
26. Copyright Drecom Co., Ltd. All Rights Reserved.
26
MQTTとは
MQTT(MQ Telemetry Transport)
• MQTTとは、publish/subscribeモデルに基づ
くメッセージプロトコル
• 低速・不安定なネットワークで動作するための
機能や非力なデバイスで動くための軽量化、同
期通信な点などが特徴
• 事例:
Facebook Messenger など各種Chat
27. Copyright Drecom Co., Ltd. All Rights Reserved.
27
歴史
1999年よりIBMが主導で商用製品提供も
2011年 Eclipse Foundationへコード寄贈
2013年 OASIS 国際標準化団体で標準化へ
・・・ 発展途中 ・・・
Ø 近年ではサービス提供事業者も
Ø Protocol仕様はロイヤリティフリー
Ø サーバー/クライアント実装複数
28. Copyright Drecom Co., Ltd. All Rights Reserved.
28
特徴
• 軽量:固定ヘッダーは2byte,
Payload: Max256MB
• Topic:送受信先. 階層構造
• QoS:
• Will
• Retain
• CleanSession
※TCP Connection NAT配下でも問題なく動作。
0:At
most
once
1:At
least
once
2:
Exactly
once
29. Copyright Drecom Co., Ltd. All Rights Reserved.
29
概要:Pub/Subモデル
MQTT Broker
publisher
Subscriber
Topic例:
/cedec/2015/room315/iot
/cedec/2015/room315/gameengine
/cedec/2015/room315/#
/cedec/2015/+/iot
A
B
C
D
A
B
A B C
A D
31. Copyright Drecom Co., Ltd. All Rights Reserved.
31
実装について
マルチプレイバトルにおける
• 全体概略
• サーバー実装概略
• アプリケーション実装
33. Copyright Drecom Co., Ltd. All Rights Reserved.
33
MQTT
Cluster
BackEnd全体構成 Draft
internet
Client
pub
/
sub
/
http(rest)
LB
(MQTT) LB(web)LB
(HTTP)
Web/
AP
Web/
AP
Web/
APWeb/
AP
KVS DBDBKVS
Reverse-‐Proxy
MQTT
Broker
REST Worker
MQTT
BrokerMQTT
BrokerMQTT
Broker
direct
routing
※検討当時資料
34. Copyright Drecom Co., Ltd. All Rights Reserved.
34
BackEnd構成概略
internet
Client
pub
/
sub
/
http(rest)
LB(web)
Web/
AP
Web/
AP
Web/
APWeb/
AP
KVS DB
MQTT
BrokerMQTT
BrokerMQTT
BrokerMQTT
Broker
direct
routing
※検討当時資料
35. Copyright Drecom Co., Ltd. All Rights Reserved.
35
利用方法概略
• MQTT Broker Serverを
BattleInstanceServerの位置づけで利用。
• Broker Serverの利用:
– Topic Room
– Room管理はAPIServer制御
– Broker ServerよりMessageを配信
– QoS 再現性/信頼性コントロール
37. Copyright Drecom Co., Ltd. All Rights Reserved.
37
Room
MQTT
Broker
Web
AP
MQTT
Broker
MQTT
Broker …
同期接続(mqtt)
非同期接続(http)
Room
Matching
Game
Client
マルチプレイバトルの接続イメージ
38. Copyright Drecom Co., Ltd. All Rights Reserved.
38
MQTT Broker
Game
Host
Client
1
同期接続(mqtt)
非同期接続(http)
Room
Guest
Client
2
Guest
Client
3
Guest
Client
4
バトルターンのイメージ
SessionMasterとして
同期委譲管理
Web/AP
39. Copyright Drecom Co., Ltd. All Rights Reserved.
39
WebAPIサーバー
• マッチング処理:
– ロビーにてマッチング処理(非同期)
– ルーム管理:
作成,メンバーJOIN/CANCEL,中断/再開,終了,破棄
40. Copyright Drecom Co., Ltd. All Rights Reserved.
40
WebAPIサーバー
• Clientが接続する
Broker Serverを選定しBalancing
• ノード死活監視、cacheリスト化
• リストから Least connections で接続
41. Copyright Drecom Co., Ltd. All Rights Reserved.
41
BrokerServer選定
• 検証観点
– 1台あたりの性能・コストパフォーマンス最
大化を重視
– 高負荷時の安定性
• 最終候補
– Mosquitto
→シングルスレッド、クラスタ無し(要自作)
– RabbitMQ with MQTT Plugin
→マルチスレッド、クラスタ有り(要検証)
42. Copyright Drecom Co., Ltd. All Rights Reserved.
42
BrokerServer開発
• RabbitMQ with MQTT Plugin利用
– MQTT自体仕様のみで実装はプロダクト依存
– 不足機能の実装例
• topicの制限や禁止
• Payload Size制限
• Client操作の制限(Server設定値)
• Queues expire化
• MQTT向けのlogging
言語: erlang
43. Copyright Drecom Co., Ltd. All Rights Reserved.
43
BrokerServer構成について
• 構成案
– Broker Standalone Parallel
– Broker Clustering
※一部課題あり:Performance劣化等
• 仕様の割り切り
– Cloudの性質上可用性には限界あり
– FailOverの検知復旧時間と体感待ち時間とのト
レードオフ
→Standaloneで利用
44. Copyright Drecom Co., Ltd. All Rights Reserved.
44
BrokerServer ScaleOut
• Standaloneのためインスタンス増設で
ScaleOut
• AWSを利用しAutoScalingを実現
– CPU使用率監視
• 研究としてスポットインスタンス利用すること
でコスト圧縮も可能
– 手法詳細はslideshareにて。
http://www.slideshare.net/GedowFather/gedow-‐style-‐aws-‐spot-‐instance
47. Copyright Drecom Co., Ltd. All Rights Reserved.
47
MQTTクライアント選定
• フルスクラッチから書く
• Paho Embedded
• Mosquitto
調査の結果この3点が候補に挙がりました
48. Copyright Drecom Co., Ltd. All Rights Reserved.
48
フルスクラッチから書く
• 全部自分で作る
• 全部自分で作るので比類無き自由度
• 全部自分で作るので工数爆発
• (実は30%位作った)
49. Copyright Drecom Co., Ltd. All Rights Reserved.
49
paho
• Eclipse Foundation謹製
• ANSI Cで書かれ、データ処理だけを提供する
ので移植性と実装の自由度が高い
• 通信部分は自力で実装する必要あり
50. Copyright Drecom Co., Ltd. All Rights Reserved.
50
Mosquitto
• 古くからあるMQTTブローカー
• コア部分がlibmosquittoとして分離されており、
単体のMQTTクライアント/サーバーライブラ
リとして利用可能
• リッチな高レベルAPIが揃っている
51. Copyright Drecom Co., Ltd. All Rights Reserved.
51
MQTTクライアント選定
検証の結果、Mosquittoを選定
• Cで書かれておりコンパクト
• コードが綺麗で読みやすい(もしもの時に重要)
• 外部ライブラリ依存が皆無
• BSDソケットさえあれば何処でも動く
52. Copyright Drecom Co., Ltd. All Rights Reserved.
52
Mosquittoの難点
• BSDソケットを使っているが、iOSで動作が怪
しいヶ所が多数
• pthreadを使っているがiOS/Androidで未実装
の関数(排他周り)を多数使用
• 他にも色々と・・・(主にシステムコール周り)
53. Copyright Drecom Co., Ltd. All Rights Reserved.
53
内製ライブラリ”Bisque”
Thread/Socket周りを
クロスプラットフォーム基盤として開発している
”Bisque”を利用した置き換え実装を行いました
54. Copyright Drecom Co., Ltd. All Rights Reserved.
54
内製ライブラリでの解決
• Socket/pthreadの弊社ライブラリBisqueで置き換え
を実施
• ただし、Mosquittoのソースには手を加えない
-> includeオーバーライド
+ Redefineリューション!
// ライブラリビルド時に定義
#define pthread_create BQ_compat_pthread_create
#define pthread_join BQ_compat_pthread_join
#define pthread_cancel BQ_compat_pthread_cancel
56. Copyright Drecom Co., Ltd. All Rights Reserved.
56
内製ライブラリ”Bisque”
• ソースコードレベルでクロスプラットフォームを実現
する為のライブラリ群
• スマホからサーバーまで、対応可能なプラットフォー
ムのAPIを抽象化
• ゲームエンジンや他処理系への組み込みを意識し、
可能な限りプリミティブに設計
57. Copyright Drecom Co., Ltd. All Rights Reserved.
57
内製ライブラリ”Bisque”
同一ソース群から3エディションが存在します
Bisque
Workstation
Edition(PC版)
Bisque
Bisque
Datacenter
Edition(サーバー版)
58. Copyright Drecom Co., Ltd. All Rights Reserved.
58
サウンド用I/F
OpenAL OpenSL /dev/audioXaudio2
下回りの実装は最適
なAPIを選択
アプリ開発者にはプラッ
トフォームを意識させな
い
61. Copyright Drecom Co., Ltd. All Rights Reserved.
61
サーバー(Ruby)
クライアント
Bisque
アーカイブモジュール
Bisque
アーカイブモジュール
全く同じコードから生成されるので
完全互換のデータ持ち回りを実現
62. Copyright Drecom Co., Ltd. All Rights Reserved.
62
・Windows
Phone
8
・Windows
10
Mobile
・iOS
・Android
・Tizen
対応プラットフォーム(2015/08
現在)
スマートフォン
PC系
・Windows
Vista以降(i386/amd64/ARM)
・Solaris
8以降
・Linux
(kernel
2.6.32以降)
・MacOS 10.5以降(PPCもOK!)
・OpenVMS
(Alpha)
・*BSD
64. Copyright Drecom Co., Ltd. All Rights Reserved.
64
Topicの構造
ROOM/
Common System Private Host
“部屋”に対して4つのTopicがぶら下がる構造
この構造がセッション毎に作られる
65. Copyright Drecom Co., Ltd. All Rights Reserved.
65
Topicの構造
System Private Host
Topicを分ける事でメッセージフィルターを実現
メッセージの振り分けをシステムに任せる
ROOM/
Common
66. Copyright Drecom Co., Ltd. All Rights Reserved.
66
Topicの構造
Common
ホストからのゲストへのメッセージ配信用
ゲストプレイヤーがSubscribe
System
システムメッセージ用
全員がSubscribe
Private
ゲストへの個別メッセージ用
各員がPrivate/<プレイヤーID>にSubscribe
Host
ホストプレイヤーへのメッセージ用
ホストがSubscribe
67. Copyright Drecom Co., Ltd. All Rights Reserved.
67
Topicの構造
Commonホスト
ゲスト
ゲスト
例:ホストプレイヤーからのメッセージ配信
ホストはpubだけ(subしない)
ゲストはCommonにSub
69. Copyright Drecom Co., Ltd. All Rights Reserved.
69
Topicの構造
Host ホスト
ゲスト
ゲスト
例:相互死活判定(ライブパケット)
ゲストはHostにPub
70. Copyright Drecom Co., Ltd. All Rights Reserved.
70
Topicの構造
Private/ゲストIDホスト ゲスト
例:相互死活判定(ライブパケット)
ホストは送信元のゲストに返信Pub
71. Copyright Drecom Co., Ltd. All Rights Reserved.
71
Pub/sub
・Topicを分ける、Subscribeする物を選ぶ事で必要なメッセー
ジだけを受信する事が出来る
・SubscribeしたTopicのメッセージは全て飛んでくるので自分
でPublishした物も受信してしまう
・Pub専用、Sub専用、Pub/Sub両用を使い分ける事により細
かいメッセージ制御が可能
72. Copyright Drecom Co., Ltd. All Rights Reserved.
72
QoS
・崖っぷちバスターズ®ではQoS0とQoS1を使用
・欠損しても影響の無いデータはQoS0
・欠損が許されないデータはQoS1
75. Copyright Drecom Co., Ltd. All Rights Reserved.
75
タップ〜ヒットまでのpub
タップ
移動・スワイプ
ヒット
QoS1のメッセージさえ届けばゲームが成立するように設計
QoS1
QoS0
76. Copyright Drecom Co., Ltd. All Rights Reserved.
76
その他
・pubの量を減らす為、メッセージにプライオリティーを
付け即時送信する必要の無いデータはバッファリン
グしてから塊で送信
・QoS1でクリティカルな物には返信要求ビットを立て、再送さ
せるメカニズムを作成
・これにより1ゲーム2000アクションで100pub、総通信量を
100KB程度に抑える事に成功
79. Copyright Drecom Co., Ltd. All Rights Reserved.
79
Mosquittoで構築したサーバーにSSL有無で1000回pub
(とあるAndroid
スマートフォン)
セキュリティー
pubだけでSSL無しの約10倍
該当端末ではゲームに支障を来す可能性も
星の数程あるAndroid端末では同じ現象が起きる端末の存在を否
定できない
SSL無し
SSL
一部 Android端末でSSLが遅い!
80. Copyright Drecom Co., Ltd. All Rights Reserved.
80
“Bisque”難読化ライブラリ採用
• 通信の難読化には弊社タイトルで実績のある内製難読化
ライブラリを採用
• 改竄防止が主な目的なので本格的な暗号は必要ない
• ゲームで3タイトル、その他アプリでも利用されています(本
当にクリティカルなデータはSSLを使用)
• アルゴリズムは複数ありますが、今回は128bitブロックの
物を採用(送信データはほぼ1ブロックに収まる)
81. Copyright Drecom Co., Ltd. All Rights Reserved.
81
難読化ライブラリのチューニング
1024バイトの文字列を1000回難読->復号を繰り返した結果
チューニン
グ前
チューニン
グ後
高速性には定評があるが、リアルタイム通信での使用
に耐える為、対応アーキテクチャー全てでベクタライズ
を中心とした徹底的ハンドオプティマイズを実施
82. Copyright Drecom Co., Ltd. All Rights Reserved.
82
その結果・・・
• AES128(弊社はUnityで利用)より250倍速く
• 前バージョン比8000%高速化
• (コード行数50倍)
AES128
チューニン
グ前
チューニン
グ後
83. Copyright Drecom Co., Ltd. All Rights Reserved.
83
データ構造
• 高速でコンパクト
• Protocol BuffersよりもプリミティブなAPI
• サーバー側(スクリプト言語)との相互運用に優れる
通信内容はmsgpackを採用
84. Copyright Drecom Co., Ltd. All Rights Reserved.
84
データ構造
MQTTではプリミティブなデータが飛び交うので
通信内容のコンテナ化を実施しました
ヘッダー 実際のデータ(msgpack)
付帯
データ
※何かに似てますが、“それ”とは違います
85. Copyright Drecom Co., Ltd. All Rights Reserved.
85
データ構造
複数のデータを固めて飛ばす可能性を考え
チェーン構造を取れるように設計
ヘッダー データ
付帯
データ
ヘッダー データ
付帯
データ
86. Copyright Drecom Co., Ltd. All Rights Reserved.
86
データ構造
難読化
このデータを難読化して送受信します
※1000レコード連結した実際のデータをビットマップにしています
87. Copyright Drecom Co., Ltd. All Rights Reserved.
87
データ構造
シンプルに汎用性を高く設計したため、セーブ
データやHTTP通信のデータコンテナとしても採
用されました
88. Copyright Drecom Co., Ltd. All Rights Reserved.
88
テスト
• 地下鉄(接続が頻繁に切り替わる)
• 社内スマホ用Wi-Fi(昼休みに不安定)
• ヴィンテージWi-Fiルーター(パケット損失多発)
• 激しい帯域制限を掛けたVPN
• 居酒屋
• 野外
実際にプレイされる環境を想定した検証を実施
95. Copyright Drecom Co., Ltd. All Rights Reserved.
95
わかった事
• LTE〜3G〜圏外を繰り返す洋上でも再接続するとBrokerが保持している限りQoS1のメッセー
ジが飛んでくるのでゲームが成立する
• Willは、通信速度が極端に不安定になる悪天候の川沿いでpingに答えられないケースが多数
(これに関してはサーバー依存の可能性も有り)
• 利根川の高圧線の下では切断多発でゲームにならないのでやめてください(iOS)
• クライアント側で実装しなくてもメカニズムでカバーしてくれるMQTTの洋上での可用性は救世
主クラス!
• 特殊な環境でのプレイテストは机上や疑似環境では起こらないナチュラルなトラブルが発生
するので、是非やりましょう
96. Copyright Drecom Co., Ltd. All Rights Reserved.
96
今後について
BisqueのTCP周りはIPv6に対応済みなので今
後も踏まえてPaho Embeddedに移行予定です
98. Copyright Drecom Co., Ltd. All Rights Reserved.
98
考察
• MQTT BrokerServerを選択し、リアリ
タイム通信ならびにターン制ゲーム実装
はゲーム仕様マッチのため可能。
• MQTT protocolやBrokerServerにも課
題はあり、要継続改善。
100. Copyright Drecom Co., Ltd. All Rights Reserved.
100
選定技術の今後について
• RabbitMQ with MQTT利用
– erlangによる実装知見
– 今後の発展型:
ターンベース→MO/MMO/MOBAの可能性
• Rubyを中心にしたWeb技術
– MQTT protocol ライブラリ
– Elixirの採用とBEAM親和性
101. Copyright Drecom Co., Ltd. All Rights Reserved.
101
リアルタイム技術トレンド
– OSSその他protocol例
• HTTP1.1
• CoAP
• (SPDY)
• HTTP2
• Reliable UDP
• MessagePack
• ProtocolBuffers
– 独自・汎用実装
• OSS
• ネットワークエンジン
• IoT PaaSの登場
• 自社・自前開発
– 市場の変化
• 例: IPv6への対応
102. Copyright Drecom Co., Ltd. All Rights Reserved.
102
IoTの今後
• IoTとしての決定版は?
– Protocol
– インフラ基盤の構築(内製、クラウド)
– デバイス疎/密連携
– 継承・委譲関係
• マクロ、ミクロのアクション・オペレーション
• ゲームでの利用
– 特定環境(アミューズメント施設、販売店舗)
– コンシューマ環境(ホーム、モバイル)
103. Copyright Drecom Co., Ltd. All Rights Reserved.
103
まとめ
• リアルタイム通信にMQTT選定
• 弊社事例を元に、MQTTの
リアルタイム通信ゲーム実装の紹介
• 今後のIoT技術への期待