Javaネットワーキングの細部

• (080413)
  【Socket I/OではObjectIOStream(GZIPIOStream(socket.getIOStream())による圧縮オブジェクトストリームは使いづらい】このわりとレアな問題について、簡明な記事をここに書こうと思っていましたが、どんどん日にちばかりが過ぎ去っていくので、とりあえず[元ネタのURL]を紹介しておきます。実用ソリューション(reply 8)は、圧縮オブジェクトを単純にバイト配列として作り、そのバイト配列をソケットでI/Oし、受信したバイト配列からオブジェクトを取り出す（再構成する）という穏健平凡な方法です。つまり、ソケットのI/Oストリームから直接ObjectIOStream(GZIPIOStream(socket.getIOStream())を作らない/使わないのです。…なぜ使わないか/使えないか、その説明がけっこうややこしいので、当面は上記「元ネタ」をじっくり読んで理解してください。


• (080308)
  【ソケットやストリームをclose（など）すると相手側に何が起きる？】この件について、[わかりやすい表]を作りました。


• (080222)
  #【初心者の錯覚やエラー(2)】[この質問者]は、JSSEのトラストストアに、ランタイムに新しい証明書をロードし、それをそのランタイムの間に有効化しようとして、ejp氏に叱られています。


• 【Socketのコンストラクタ】Socketの４引数のコンストラクタは、ファイアウォールなどの存在によって、使えるローカルアドレスやローカルポート（とくに後者）に制限があるときに使います。


• 【プロキシの設定】HTTP Proxyは、URLConnectionを使うときに関係してきます。Socketに対しては、SOCKSや、Proxyオブジェクトを使うSocketのコンストラクタが関連します。


• 【readLine()に対するprintln()の使用】受信側がBufferedReaderのreadLine()を使っているときは、送信側が行末の'\n'を送らないとreadLine()がブロックするので、安全確実のためには、BufferedWriterでwrite()してnewLine()してflush()するよりも、PrintWriterをautoFlush=trueでコンストラクトし、println()で各行を送信すべきです。（ただし、PrintWriterは例外を投げないので、開発/デバッグ時や、あまり常時安定していないネットワーク環境やホスト環境では使わないほうがよいでしょう。ネットワークアプリケーションでは絶対使うな、と本書の原著者は厳しく主張しています。私は、簡単な、要求がシビアでないアプリケーションでは使っていい、と気楽に考えます。）


• 【readUTF()とwriteUTF()はペア】受信側がreadUTF()でリードしているときは、送信側は必ずwriteUTF()を使うべきです。送信側がnon Javaの場合には、writeUTFを正確に模倣する必要があります。一方、送信側がwriteUTF()を使っているなら、受信側は必ずreadUTF()またはreadUTF()相当の関数でリードする必要があります。（逆に言うと、相手がwriteUTF()を使っていることが確実でない接続では、受信のためにreadUTF()を絶対に使うべきではありません。サーバの送信仕様（文字コードなど）を、まず正確に知るべきですね。）


• ひとつのソケットの、入力ストリームと出力ストリームをjava.ioの高級ストリームやReader/Writerでラップした場合、そのソケットがクローズされるまでずっとそれを使い続けるべきです。途中でいろいろ変えると、トラブルの元です。この参考ページを読んで見ましょう。


• #【初心者の錯覚やエラー(1)】[この質問]のプログラムの作者は、サーバへの最初の接続をクローズしないまま同じクライアントホストから同じサーバに再接続すると、最初の接続が維持継続する、と錯覚しています。