ImageIOクラスでの画像入出力時にカスが残るエラーについて

質問

現在クライアントとサーバ間で画像の受け渡しを行うプログラムを作っています。

(1)クライアントからサーバへ文字列を送る(PrintWriterを使って出力)
(2)サーバはクライアントにレスポンス(これも文字列)を返す(PrintWriterを使って出力)
(3)サーバからクライアントへ画像を送る(ImageIOを使って出力)
(4)クライアントは受け取った画像(ImageIOで入力したもの)を処理する
という順序で処理を行っています。

このサイクルを同一プログラム中に繰り返し行った時に、２回目以降に(2)の工程で送るべき文字列の頭に一回目に送った画像の残りカスと思われるデータがついてしまったのか、
クライアント側で受け取った文字列を表示させてみたところ変なバイナリデータがついてしまっていて正しい処理が行われません。
その後のサイクルではImageIOで出力しても、クライアント側で受け取った時には画像データとしてではなく、複数行の文字列として扱われてしまっています。
どのような対策をすれば残りカスの発生を防げるのでしょうか？
どなたか詳しい方がおられましたら教えてくださいm(_ _)m
お願いします。

回答No.3

_ranco_

> 毎回確実にflush()はしています。
そうですね。Javaのストリームをflush()してもTCPの送信バッファはフラッシュされませんからね。こんな単純なことを、忘れていました。

なお、Socket通信の重要なコツの一つは、I/Oストリームの性質を途中で変えないことです。たとえば、Reader/Writerでストリームをラップしたら、最初から最後までそれを使い続けること。

私が昔書いた画像ファイルサーバは、文字列情報（画像タイトル、ファイル名、説明文など）と画像データを合わせて一つのバイトデータを作り、それをストリームでwrite()していました。サーバ側もクライアント側も手間は増えますが、送受信そのものは究極的にシンプルで堅牢で安全です。

お礼

ラップはやり直さない方がいいとは全く知りませんでした。
サーバ側での処理は極力負担をかけないようにしたいので、バイトデータに全てまとめるというのも難しいかもしれません。
まぁ少しの違いかもしれませんが…

しかし、今回は初めての開発だったので、設計段階での粗が目立ち反省しています。
頂いたアドバイスも含めて成長していきます。

回答No.2

_ranco_

毎回々々のPrintWriter出力とImageIO出力(OutputStream)を、どちらも確実にflush()していますか？

補足

_ranco_様
はい。PrintWriterでの出力の際もImageIOでの出力の際も毎回確実にflush()はしています。

回答No.1

Bonjin

簡単な対処としては、FTPの様に制御用とデータ用のコネクションを分けることが考えられます。
ImageIOが送信したデータを全て読み込む保証が無いので同一コネクション上で処理をするなら、ちゃんとプロトコルを設計した方がよいです。

補足

ご指摘ありがとうございます。
ImageIOがデータの到達性を保証しないというのは知りませんでした。
ひとつのソケットに対しては他に対策は考えられませんでしょうか？