closeされたsocketへの動作について

現在、javaを使用してプログラムを作成しているのですが、closeされたsocketに対しての動作について質問があります。

クライアント側のプログラムに

ObjectOutputStream.writeObject(send);
ObjectOutputStream.flush();
ObjectInputStream.readObject();

というものがあったとします。

サーバ側でsocketをcloseし、上記のプログラムを走らせた場合writeObjectにてsocketExceptionを検出する場合とreadObjectでEOFExceptionを検出する場合の２パターンが起こりうるのですが、これはなぜでしょうか？

なお、上記のwriteObjectの引数のsendはＳerializeを継承して作成した自作クラスのオブジェクトです。

No.1 回答者： anmochi 回答日時： 2011/12/03 21:06

　はい、ではTCPがどういう風に開始、終了するのかと合わせて確認してみましょう。

　まず、
１．Socketはサーバ側が待ち受け（Listen）しており、
２．クライアント側が接続（connect）して、
３．サーバ側が受け入れ（Accept）して通信が可能になる。
この時、TCP層では２のタイミングでクライアントからサーバにSYNパケットというものが送信される。その後、３でサーバからクライアントにSYN+ACKパケットが返送され、最後にクライアントがACKパケットをサーバに送りつけて完了だ。これで双方は「相手と現在つながっている」という認識を行う。

　そして終了だが、ソケットアプリケーション（JavaのSocketクラスも例外ではない）は、ソケットを閉じる時に以下の手順に従わなくてはならない。以下はJavaのSocketOutputStreamとSoketInputStreamでイメージしやすいように記述する。
１．相手に届けたいものがあれば気の済むまで届ける。
２．ライト側すなわちSocketOutputStreamをclose()する。
３．EOFになるまでSocketInputStreamから読み出す。EOFになったのに読むとEOFException。
４．EOFになったSocketInputStreamをclose()する。
これを双方が行わなくてはいけない。一方がそれこそ一方的に切断してしまうと、もう片方はConnection Reset by peerになってしまう。
分かるだろうか。お互いがOutputを切る事で相手に通信の終了を伝え、相手はInputがもうない事を確認した上で切断する。この時、TCPでは双方とも相手にFINというパケットを投げる事で「こっちはもう出力側をクローズしたぜ。」と伝える。

　前置きが長くなったが、サーバが勝手に接続を切った時、クライアント側でWriteのタイミングで例外が起きたりReadのタイミングで例外が起きたりする、とは、Writeのタイミングで例外が起きたり起きなかったりする、と言い換える事ができる。
　Write側は相手のRead側とつながっているけど、前述の通りWriteが先に切るのがお作法というかもう不文律レベルの話だ（いや、どっかで明文化されているのかも知れんけど）。なので、Write側は「相手が勝手に切っちゃう」なんて状況を想定していない。
　で、相手が勝手に切っちゃってた時の動きだけど、スローされない場合があるのは、サーバ側のプログラムでSocketをclose()した後、実際にTCPを切断するタイミングを制御するのはOSであり、OSはしばらく待っているからだ（OSから見ればクライアントからFINパケットを受け取っていないので待つしかない）。クライアント側のプログラムはWriteしてサーバには届いたけど、サーバ側のプログラムはもうSocketInputStreamを閉じてる認識なので読み出す事はないという状態だ。サーバ側のOSとしては自分は相手にFINを送ったのに相手からはそれに対するACKも送られてこないし、もう通信は終わらなきゃいけないのに相手からはFINが送られてこない、という状態になっている。しばらくは待ってみるけど、OSが待つと決めた時間が過ぎる（タイムアウト）と、それも切ってしまう。切られてなけりゃクライアント側のWriteは成功するし、切られてたら失敗する。このタイミングはOSによりけりだ。

　ついでに、ReadのタイミングでEOFExceptionなのは、前後のプログラムをみてみないと分からないな。EOFか確認せずにReadしたらそれは当然EOFExceptionになる。