#gamelift

その名もGomeLift。https://github.com/neguse/gomelift

GomeLiftを使うと、Goを使って開発したサーバをGameLiftにデプロイできるようになります。これにより、例えばリアルタイムに通信してゲームの状態を管理するサーバをGoで開発しているケースでは、サーバのスケーリングやマッチメイキングをGameLiftにお任せできるようになります。

現状は、とりあえず公式のServer SDKの機能をほぼまるまる移植して、サンプルが一応動いたという程度の状態です。もし使ってみた方がいましたら、お気軽に感想や要望など、GitHubのIssueや twitter:neguse までご連絡ください。

開発の動機、履歴を追いたい方は以下のログを参照ください。たぶん最初の記事が一番くわしいです。

https://www.neguse.dev/post/190754792208/gamelift%E3%81%AEgo%E7%94%A8server-sdk%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F%E3%81%841

https://www.neguse.dev/post/190858174313/gamelift%E3%81%AEgo%E7%94%A8server-sdk%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F%E3%81%842

https://www.neguse.dev/post/190965430813/gamelift%E3%81%AEgo%E7%94%A8server-sdk%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F%E3%81%843

https://www.neguse.dev/post/612563897674809344/gamelift%E3%81%AEgo%E7%94%A8server-sdk%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F%E3%81%844

https://www.neguse.dev/post/613280040330854400/gamelift%E3%81%AEgo%E7%94%A8server-sdk%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F%E3%81%845

https://www.neguse.dev/post/613911685911248896/gamelift%E3%81%AEgo%E7%94%A8server-sdk%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F%E3%81%846

https://www.neguse.dev/post/614570811455651840/gamelift%E3%81%AEgo%E7%94%A8server-sdk%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F%E3%81%847

AWSにBuildとしてGomeLift https://github.com/neguse/gomelift を組み込んだサーババイナリをデプロイしてみて、セッション(GameSession, PlayerSession)の管理ができることを確認できた。長かった～～

あとはBackfillだけ試して機能的には一通り完了として、テストに使ったサーバなどのプログラムをサンプルコードとしてコミットして、ドキュメント書けばひとまず完了とできそう

一方、GameLiftにアップデートが来ていて、「GameLift FleetIQ with game server groups 」という機能がプレビュー公開されていたhttps://twitter.com/neguse/status/1245943776893255680

前回からの引き続き https://github.com/neguse/gomelift 通信をWebSocketに切り替えて、GameLiftLocal(ローカル環境で動くGameLiftエミュレータ)では一通り動くような気がしてきた。切り替えはもっと手間がかかるかと思っていたけど、Engine.IOのレイヤーにしか影響がなかったのであまり手間がかからなかった。あとは本物のGameLiftに載せて動くことが確認できれば完了とできそう。

前回から引き続き。https://github.com/neguse/gomelift

クライアントから送ったメッセージに対してのAckを受け取るところは、思ったよりあっさり作れた。送信時にchannelを作成してmessage idをキーにしたmapにchannelを格納してchannelをreceive、受信時にmapからchannelを取り出して送信したら後続の処理が行われるという方法。

GameLiftServerSDKに付属しているGameLiftLocalサーバを使ってテストしているのだけど、1分強接続すると勝手に切断する問題が出てて、どのレイヤー(engine.io, socket.io, gameliftクライアント)が問題なのかわからないので詰まっている。たぶんengine.ioなんじゃないかという気がするのだけど、でもping/pongはできてるはずで、node用のsocket.ioサーバに接続した場合は問題なく接続が維持できてるっぽい。なぜ…

公式SDKでも同様のクライアントを組んでみて、パケットキャプチャして比較してみるとかかなぁ。でもそれだとWebSocketが使われそうなので(GomeLiftでは手抜きのためHTTP Pollingを使っている)、同じ方式を使うためにまずTransportをWebSocketに置き換えてみるのが良いかもしれない。

未完成だけど、リポジトリを作った。https://github.com/neguse/gomelift

前回からSocket.IOの実装を行って、ライブラリとしての形ができつつある。結局Ackを返すためにはgomasioは使えず、自前で Socket.IOを実装している。だいぶ手抜きではあるが、一応StartGameSessionに対してAckを返して、ゲームセッションの作成が完了するところまで確認できている。

ある程度形になったあと、他にもSocket.IOクライアントのGo実装をしていた方を見かけた。 https://github.com/graarh/golang-socketio 一旦見なかったことにしてすすめる。メンテ放置されてそうだし…

サーバから来たメッセージに対するAckを返すのは割と簡単にできたが、クライアントから送信したメッセージに対するサーバのAckを再度クライアントで受け取れるようにするところがちょっと難しそう。メッセージのIDをもとにどこに返すかを覚えておく必要があるが、Goだとチャンネルを使うのがいいのだろうか。インタフェースいじらないと難しいかも。

また、受信したメッセージをデシリアライズするところがあまりきれいに書けていない。こちらももう少しインタフェースを考えないといけなそう。

引き続き、engine.ioのクライアント実装を書いてみる。

https://gist.github.com/neguse/05a497f651c99455caa1410282caf049

実際に書いてみると理解が間違っていたところがあった。

XHRの場合、Client→Serverのデータ送信はClientからのPOSTリクエストに載っているのだけど、このPOSTのレスポンスにServer→Clientのデータ送信も(バッファに溜まっている場合)含まれるものだと思っていた。これは違っていて実際にはPOSTレスポンスには”ok”という文字だけが入っていて、Server→Clientのデータ送信はClientからのGETリクエストのレスポンスにのみ含まれる。

ということで、まずEngine.IOを調査してみた。 websocketだけの実装ではだめっぽいので、少なくともpolling/xhrは必要そう。

XHRクライアントに限定したら簡単に実装できそうかなあという印象。 upgrade周り含めるとちょっと面倒そう。 あと、AckはEngine.IOには含まれてないのでSocket.IOまで見る必要がありそう。

次は、簡易でいいのでEngine.IOのGoクライアントを用意してみる。

以下メモ。

https://github.com/socketio/engine.io-protocol https://github.com/socketio/engine.io-parser https://github.com/socketio/engine.io-client

TransportはEngine.IOのURLに対して接続を確立する サーバはopenに対してsid, upgrades, pingTImeout, pingIntervalを含む返信をする サーバはpingに対してpongしなければならない クライアントとサーバはmessageパケットを自由に交換する(おそらくRequest-Responseのように対になることなくそれぞれ勝手に、という意味) PollingしているTransportはソケットを閉じるためcloseを送ることができる?since they're expected to be "opening" and "closing" all the time.がよくわからん

URLは/engine.io/[?<query string>] という形式。 queryはオプショナルで、transport, j, sid, b64の4つが予約されている。 transportはTransport名で、デフォルトではpollingかwebsocket jはtransportがpollingでJSONP responseが要求されている時、JSONP response indexが設定される sidはセッションID。クライアントがセッションIDを与えられたら指定する必要あり b64はクライアントがXHR2をサポートしていない時b64=1となって、バイナリはbase64エンコードされて送られる

エンコーディング

packetとpayloadがある

packetはUTF8文字列かバイナリデータ 文字列の場合、以下のフォーマット

<packet type id>[<data>]

バイナリでも同じだけど、packet type idのところが最初の1バイトになる

パケットタイプは以下のものがある

0 open 新しいTransportが開いた時サーバからクライアントに送られる

1 close Transportを閉じる要求だが、自身のコネクションは閉じない? (TransportとConnectionの違いがわからん?)

2 ping 3 pong Pingに来たデータをそのままPongする必要ある

4 message データをコールバックに渡して呼ぶ必要がある(プロトコルというよりライブラリの話)

5 upgrade Transportを切り替える前に新しい接続方法でいけるかテストする。テスト成功したらクライアントはupgradeを送って、新しいTransportに切り替わる。

6 noop poll cycleを強制するためincoming websocket connectionを受け取った場合に使われる? (よくわからん)

payload

いくつかのパケットをつなげたもの

<length1>:<packet1>[<length2>:<packet2>[...]] つまり長さとパケットが交互に来る形 lengthは文字数で表現する packetは上で説明した通り

XHR2がサポートされていない時はbase64エンコードされた文字列として送信する それを示すためにbという文字がくっつく

<length of base64 representation of the data + 1>:b<packet1 type><packet1 data in b64>

XHR2がサポートされている時はこれ

<0 for string data, 1 for binary data><Any number of numbers between 0 and 9><the number 255><packet1 first type, then data>[...]

UTF8文字列とバイナリデータの組み合わせが送信される時は、各文字の文字コードが1バイトずつ書き込まれる?

Payloadはframingをサポートしていないtransportで使われる。pollingとか

Transport

websocket, pollingがある pollingにはjsonpとxhrがある

pollingは、クライアントからサーバに対する定期的なGETと、データ送信時のPOSTからなる

xhrではCORSレスポンスをサポートする必要がある jsonpではサーバは正しいJavaScriptを返信するよう実装する必要がある websocketではフレーミングをサポートしているためpayloadは使ってはならない