ＴＣＰ／ＩＰ通信でのコネクションロスト（ソケットエラー）の検知について

質問

インターネット上での対戦ゲームの作成を行なっているところです。
サーバーを挟んでクライアント間で双方向の通信を行なっています。

　Ａ　→　サーバー　→　Ｂ
　Ａ　←　サーバー　←　Ｂ

ＴＣＰ／ＩＰは信頼性の高い通信方法ということで、データ抜けなどは
心配しなくても良いと聞いています。
もし、データ抜けなどが発生した場合はコネクションロストの状態になると。

実際のプログラミングではソケットを使用しています。
コネクションロストが起きると、ソケットエラーかソケットクローズで検知できます。

実際に例えばクライアントＡを強制終了させるとサーバーはただちに
ソケットクローズを検知します。

ここで、問題はデータを送っても届かないのに、
ソケットエラーもソケットクローズも起きない状態が発生することです。
これはインターネットの経路上になにか問題が発生したと考えていますが
このような状態はタイムアウトなどで監視する以外に検知する方法はないのでしょうか？

クライアントはウィンドウズでＶＢ６．０のwinsockを、
サーバーはLinuxを使用しています。

なにかアドバイスをいただければありがたいです。

回答No.1

lv4u · ベストアンサー

>>これはインターネットの経路上になにか問題が発生したと考えていますが
>>このような状態はタイムアウトなどで監視する以外に検知する方法はないのでしょうか？

多くのアプリは、タイムアウトで処理しているようです。例えば、経路途中のどこかのＬＡＮケーブルが抜けて通信が失敗した場合、すぐにエラーを検出して異常になるよりも、ＬＡＮケーブルを差し込んだら、そのまま継続してくれるほうが嬉しいわけですからね。

もし、デフォルトのタイムアウトがいやなら、定期的に信号をやりとりする仕組みを組み込めばいいと思います。ただし、そのやりとり自体もタイムアウトになる可能性があるのと、連番を振って管理するなどしてエラー時の再送をやる場合、考慮無くやると、アホな結果を生む可能性もあるので、注意が必要です。このあたりの話題はソケット関係の情報を検索すると出てくると思います。

あまり厳密にやると複雑化する気もするので、シンプルにタイムアウトでの対処がいいかなと思います。

お礼

ありがとうございました。

＞すぐにエラーを検出して異常になるよりも、ＬＡＮケーブルを差し込んだら、そのまま継続してくれるほうが嬉しいわけですからね。

なぜ、すぐにタイムアウトにならないかと思っていたのですが、なるほどと思いました。

＞考慮無くやると、アホな結果を生む可能性
実は今、こういう状況で作り直すところなのです。
それでご意見を伺ったしだいです。

参考になりました。ありがとうございました。

回答No.2

noname#96023

TCPの設計概念の話になってしまいますね。
TIMEOUTが待てないなら、UDPなどを使い独自にエラー検出を行う方法などもあります。ただこちらの方が難易度が高いですが。

お礼

＞UDPなどを使い独自にエラー検出を行う方法などもあります。ただこちらの方が難易度が高いですが。

UDPと組み合わせるという方法もあるのですね。
勉強になりました。
ただ、ちょっと考えただけでもむずかしそうだなと思いました（＾＾；