|
> これはさすがにないと思いますよ。 仮に HDD がとても遅かったとしても、 >> while (<IN>) { でブロッキングするだろうから、読めなかったけど処理が 先に進むなんてことはないと思う、ということです。 # ここでブロッキングしてくれないと、OS の意味がない。 |
|
初めまして、セガＢＢＳの過去ログ凄いです、 ご苦労様としか言えません、 また、じっくり見させてもらいにきます、 （今からみるんだけど、、、） |
|
> 何バイト送ったら切れる、などという再現性はありますか? 再現性はないようです。 接続が切られた時点でのサイズは不定でした。 > 1バイトずつ送ってみるとどうでしょう。 えっと、具体的にどのようにすればいいんでしょうか？ readで1バイトずつ読んでいくのでしょうか。ちょっと試してみます。 > また、切れるのはデータコネクションですか? コマンドコネクションですか? すいません、説明が足りなかったようで。 どうやらQUITは送信されているようなのでデータコネクションが切られているようです。 >> FTPdがファイルハンドルを解放しないような状態 FTPdが起動中はエクスプローラからもファイルの削除等ができません。 もちろんスクリプトが終了していても、です。 FTPdを終了させると、送信したファイルが元サイズ以下(不定)であるという感じです。 そうなると削除等も可能になります。 「データコネクションかコマンドコネクションか」というのは自分にはわかりません。 > あと、このコードの前後数行を見せてもらえますか? 以下のようになります。 ほとんどftptrans.plを流用させて貰ってます(^^; if ($mode eq 'put') { &send_command(COMMAND, "STOR $target_file\r\n"); } elsif ($target_file =~ m|/$|) { &send_command(COMMAND, "LIST $target_file\r\n"); } else { &send_command(COMMAND, "RETR $target_file\r\n"); } &client_work(DATA, $data_connection_host, $data_connection_port); open(IN, $infile) || die "$infile: $!"; binmode(IN); while (<IN>) { print DATA $_; } close(IN) || die "close: $!"; &read_response(COMMAND); close(DATA) || die "close: $!"; &send_command(COMMAND, "QUIT$CRLF"); &read_response(COMMAND); close(COMMAND) || die "close: $!"; > # ここでブロッキングしてくれないと、OS の意味がない。 当てがはずれてたようですね(^^; 実際改善されなかったですし。 ファイルが送信し終わる前にQUITが送信されてると言うことはデータコネクションが 切断される前にコマンドコネクションが切断されると言うことでしょうか？ 確かFTPってデータコネクションの切断＝データの終わりでしたよね？ でもcloseでは死んでないようだし・・・ とりあえず1バイトずつを試してみます。 |
|
あ、すいません、訂正です > &send_command(COMMAND, "QUIT$CRLF"); &send_command(COMMAND, "QUIT\r\n"); です。 # 普段$CRLF="\r\n";でやってるもので(^^; |
|
> メリクリウスさん メールの返事をここでさせて頂きますが、人の多いところから リンクしちゃダメなのは、お肉さんのところです。うちは どこからリンクしても構いませんです。 > FTPdが起動中はエクスプローラからもファイルの削除等ができません。 FTPd が STOR 先のファイルをオープンし続けているということですね。 謎ですね。 こちらには Windows 環境がないので、そのものずばりの答えは わかりませんが、思いつくままに。 1. まずは小さなファイルでやってみて下さい。 2. sub client_work の最後で、SOCK のバッファリングを OFF にしている ($|=1) のは削ってませんよね? 3. QUIT 送信の前に &read_response(COMMAND) が一つ足りてないんじゃない ですか? データコネクションが確立したら、 150 Binary data connection for test/hogemoge (127.0.0.1,33299). というレスポンス、さらに転送が完了したら 226 Transfer complete. というレスポンスが返ってきませんか? (でもこれが原因じゃないと思う。レスポンスを読まなくても転送はできるはず) 4. $verbose=1 にして、プロトコル眺めてますよね? 5. passive なら、telnet コマンドだけを使って送信してみるのもいいかも。 6. ftp にデバッグオプションを付けて、プロトコルを観察してみては。 >> 1バイトずつ送ってみるとどうでしょう。 > えっと、具体的にどのようにすればいいんでしょうか？ 例えばこんな感じです。 &send_command("STOR $target_file\r\n"); &client_work(DATA,$data_connection_host,$data_connection_port); &read_response(COMMAND); use IO::File; sysopen(IN,$infile,O_RDONLY); binmode(IN); # sysopen なら不要かな? while (1){ $nread = sysread(IN,$buf,1); $read_size += $nread; last if ( $nread == 0 ); print "$read_size read "; print DATA $buf || die "$!"; # 成功したかどうかチェック print "$read_size send.\n"; } close(DATA); close(IN); &read_response(COMMAND); &send_command("QUIT$CRLF"); &read_response(COMMAND); close(COMMAND); とりあえず、何バイト目でこけているのかは調べられるでしょう。 ただし、パケットレベルで 1バイトずつのデータが送られる、という 保証はありません。 念には念を入れて、print DATA の代わりに syswrite(DATA,...) を 使ってみるのもいいかも。 # syswrite ＝ select(DATA);$|=1;binmode(DATA);print DATA と # 同じはずだと思うんですが、違いましたっけ。 Solaris の ftpd 相手に試していて思ったんだけど、 http://X68000.startshop.co.jp/~68user/net/ftp-5.html > 次のアクションは > データコネクションの確立なのか > コマンドコネクションからのエラーレスポンスなのか > のどちらなのかが わからないのです。 こんな変な仕様は、もしかして FreeBSD の ftpd だけかもしれない…。 調べておかねば。 |
|
はじめまして。ゲームでわからない事があったので、誰か教えて下さい。 「七ツ風の島 物語」というゲームなのですが・・・ （知っている人、いるかなぁ・・・） 第１１章 『小さくてキレイな物』・・・で、どうしたらいいのか、わかりません。 あった事といえば、白ガラスのヒューと、カンぞうに会った事です。できれば、わかる人、教えてください。よろしくお願いします。 |