|
ソケット(TCP)に関する質問です。 サーバ(UNIX)とクライアント(WinSock)がソケットで通信しています。 サーバがクライアントに対してwriteでデータを送り、クライアントがrecvでそれを読む処理を作成しました。 サーバでwriteし、すぐにソケットそcloseすると、クライアントではrecvできずにエラーになります。(既に接続が破棄されている。) サーバ側でwriteして、すぐにcloseしている事が原因の様です。 writeとcloseの間に１秒程度の時間をおくと、クライアントはrecvできました。 このように、writeとcloseが連続すると相手がrecvできないケースは当然の事なのでしょうか。 それとも、通常はrecvできるはずであり、他に問題がありそうでしょうか。 同じ経験をした事のある方がの意見なども聞けると助かります。 よろしくお願いします。 |
|
>>3135 koko > 通常はrecvできるはず だと思います。 |
|
>>3136 68user 回答ありがとうございます。 他の原因を調べてみます。 |
|
ファイルハンドルについての質問です。 Net::FTPで動的に作り出したCSVをアップしたいのですが、 ローカルにファイルを書き出さずにputする方法を教えてください。 FileHandle.pmを使って無名のファイルハンドラを作って、 そこにCSVを入れて、$FTP->put(FILEHANDLA)でアップさせる とイメージしているのですが よろしくお願いします。 |
|
>>3135 koko ソケットのクローズはどのAPIを使って（どんなソースコードで）行ってらっしゃいますか？ Winsockだと、shutdownを使わずにclosesocketを呼ぶとRSTフラグのセットされたパケットが飛ぶことが あるような覚えがあります。 いずれにせよ、パケットキャプチャしてみると原因に近づけると思います。 |
|
>>3139 金床 パケットをキャプチャしてみたところ、サーバからクライアントにRSTフラグのセットされたパケットは飛んでいました。 試したケースを整理します。 (1)accept直後にクライアントからの送信データをreadせずに、サーバ側から write、closeすると、クライアントではサーバがwriteしたデータを受信できません。 (2)accept直後にクライアントからの送信データを１バイトでも良いのでreadし、サーバ側からwrite、closeすると、クライアントではサーバがwriteしたデータを受信できます。 (2)では、RSTフラグのセットされたパケットが飛ぶ前に、FIN ACKがセットされたパケットとクライアントで受信させたいパケットが飛んでおり、(1)ではFIN ACKがセットされたパケットとクライアントで受信させたいパケットが飛んでいません。 サーバ側でクライアントの送信電文を１バイト読む事で動きが変わるようなのですが、この辺が何か関係があるのかもしれません。 ちなみに、APIは以下の通りです。 サーバ(UNIX)：socket,bind,listen,accept,select,read,write,close クライアント(WIN)：socket,bind,connect,listen,recv,send,closesocket サーバ側でのソケットのクローズは、acceptの戻り値を引数にしてcloseをしているのみで、shutdownはしていません。 |