TCP socketではwriteの後すぐにcloseしてはいけない

koba @tetsu_koba

TCPのsocketでwriteの後にすぐcloseしていると、読み込み側が最後までデータを読めないことがある。sockoptのSO_LINGERは効果なし。closeの前に2秒sleepすればうまくいく。こんなんでいいのか？？

Yasuo Itabashi @yitabashi

@tetsu_koba キューの中身を送信前に、キューを破棄してしまうのが原因だと思うので、ioctlでSIOCOUTQを見てキューの送信残が0になるのを待つと良いかと。

koba @tetsu_koba

TCPsocketのwriteの後にすぐcloseするのでなく、shutdown(sock, SHUT_WR); にして、readで読み込み側がcloseしてEOFになるのを確認してから、書き込み側をcloseするようにした。これでいいのかな？？

Tatsuo Nagamatsu @nagamatu

@tetsu_koba socketに対して shutdownを使ってみたら？

koba @tetsu_koba

@yitabashi ありがとう。ぐぐるといろいろ違うことが書いてあるけど鉄板のやりかたは無いってことなのかな。ioctlでSIOCOUTQはLinux固有らしい。今は対象はLinuxだからいいけど。

koba @tetsu_koba

@nagamatu ありがとう。とりあえずそれでうまくいってます。

Tatsuo Nagamatsu @nagamatu

@tetsu_koba 直ぐに解決していましたね

koba @tetsu_koba

TCPってエラーフリーのはずなのに！ってみんな一度は通る道なのかな。実際にやってみるまでは知らなかった。

koba @tetsu_koba

TCP sokcetでwriteでデータ書き込みしても、相手側にそれが届くまでcloseしてはいけない。shutdown(sock, SHUT_WR)で、これ以上書き込まないことを相手側に通知できる。相手側がcloseしたことはreadで0が返ってくるのでわかる。

Yasuo Itabashi @yitabashi

@tetsu_koba ノンブロックソケットにsendfile()で書き出すときも、先の方法でキューが空であることを確認してからでないとデータを上書きして壊してしまいます(2.6.18で確認。多分まだ直ってない)。バッファから吐き出した時点で書込完了通知が上がってるのが原因かと。

koba @tetsu_koba

TCPで最後のデータを受信できないのを回避する方法。 / “The ultimate SO_LINGER page, or: why is my tcp not reliable” http://t.co/kdIlBAye

koba @tetsu_koba

sockopt SO_LINGER が効果がなかったのが納得できないけど、shutdownでハーフクローズにするのは腑に落ちた。

koba @tetsu_koba

popen(3)を使って実験したけど、その後にpipe(2), fork(2), dup2(2), execv(2) で書き直した。

koba @tetsu_koba

今日はTCP socketのcloseとpipeの使い方を学んだ。経験値がアップした。

koba @tetsu_koba

@AkiraTsukamoto ありがとうございます。その本さがしてみます。

koba @tetsu_koba

もしかして、TCPのsocketをreadでブロックさせておくと相手側が切断したことを監視するのに使えるのか？別に何もデータは来ないけど切断されたらreadがEOFで戻ってくるから、そしたらこっちのプロセスも終了。

鯉江 @koie

@tetsu_koba select()で待ってreadでもいいです。ただ相手が突然死した場合にはFINパケットが来ないのでこっちからなにか投げてやる必要があるかも。KEEPALIVE onにするか自分でpingするか。

koba @tetsu_koba

TCPで接続したあと、何も通信するデータがない状態で、クライアント側が終了してもサーバ側がそれに気がつかずに、次にwriteするまでずっとプロセスが無駄に残ってしまうという問題があったけど、これで解決できるかも。

繋がれたひよこ @tomo_watanabe

@tetsu_koba Comet？ http://t.co/pO6NlxHA

koba @tetsu_koba

@tomo_watanabe HTTPのレベルじゃなくて、生のTCPソケットでやってる。

繋がれたひよこ @tomo_watanabe

@tetsu_koba なるほ

koba @tetsu_koba

@koie 物理的にケーブルが抜けた場合とか、相手側のカーネルが後始末をしない場合はreadのEOFだけだと切れたことに気がつかないということですかね。

鯉江 @koie

@tetsu_koba メッセージパッシングの限界ですね。これを超えるには物理レイヤーの情報がないと。

koba @tetsu_koba

@koie 原理的には相手は地球の裏側にあって、途中に無数のノードを経由しているかもしれないですからね。:) 明示的に終了処理されなければ、切断されたのか、時間がかかっているだけなのか判断できないと。