まず、socketによる通信の流れの再確認から。
- サーバーがlistenソケットを作成、接続要求待機する
- クライアントはlistenソケットに対し接続要求をする
- サーバーがacceptにより接続要求を承諾、通信用ソケットを作成
- listenソケットは再び接続要求待機に戻る
- 通信用ソケットを用いて通信を行う
これが基本の流れになります。
ここで、複数クライアントを受け入れない場合は、4ののちlistenソケットを閉じることで新たな接続要求を拒絶できます。つまり複数クライアントを受け入れる場合はlistenを継続し、最大数までacceptを行い、最大数に達したらlistenソケットを閉じます。
acceptした際(またはaccept前)にクライアントの各種情報を取得できるため、その情報から接続を拒絶したり、再接続に使用したりできます。
accept前に接続要求を確認するよりは、とりあえず接続要求を承諾し、問題があればエラーを返してから接続を閉じる方がサーバーとしては理想的です。
もちろん、ゲームのために最適化を優先して、接続要求をそもそも承諾しない事も可能ではあります。
本ゲームにおいては、クライアントは2つに絞ります。ゲーム起動から接続要求をしてきた最初の2つのクライアントを記憶し、仮に途中で切断され再listenしてもそのクライアント以外は許可しません。本来は接続したらまずはクライアントが正しいのかハンドシェイクする方がセキュリティ的には良かったりしますが、今回は暗号化も何もしません。個人情報などは扱いません。所詮ゲームです。最低限、不正なデータによるバッファオーバーフロー攻撃などの脆弱性にだけ気をつけておきます。
まず、socketによる通信の流れの再確認から。
これが基本の流れになります。
ここで、複数クライアントを受け入れない場合は、4ののちlistenソケットを閉じることで新たな接続要求を拒絶できます。つまり複数クライアントを受け入れる場合はlistenを継続し、最大数までacceptを行い、最大数に達したらlistenソケットを閉じます。
acceptした際(またはaccept前)にクライアントの各種情報を取得できるため、その情報から接続を拒絶したり、再接続に使用したりできます。
accept前に接続要求を確認するよりは、とりあえず接続要求を承諾し、問題があればエラーを返してから接続を閉じる方がサーバーとしては理想的です。
もちろん、ゲームのために最適化を優先して、接続要求をそもそも承諾しない事も可能ではあります。
本ゲームにおいては、クライアントは2つに絞ります。ゲーム起動から接続要求をしてきた最初の2つのクライアントを記憶し、仮に途中で切断され再listenしてもそのクライアント以外は許可しません。本来は接続したらまずはクライアントが正しいのかハンドシェイクする方がセキュリティ的には良かったりしますが、今回は暗号化も何もしません。個人情報などは扱いません。所詮ゲームです。最低限、不正なデータによるバッファオーバーフロー攻撃などの脆弱性にだけ気をつけておきます。