アプリ版:「スタンプのみでお礼する」機能のリリースについて

ふと思った事なのですが、フリーソフト等ダウンロードをFTPで行った際、たまに「ファイルが破損」しています。
といったエラーになる場合があります。

再ダウンロードするとうまく動く(解凍できたり)のです。

そこで質問なんですが、
FTPはTCPを使用していると思っています。
TCPというと参考書などには「再送制御?」なるものがあり、
確実なファイル転送がおこなえるような記述がなされています。

TCP環境下でビットの欠落が起こるえるんでしょうか?

よろしくお願いします。

A 回答 (6件)

大事な事が抜けていました。



「確実なパケット転送」の意味ですが、これは「送ろうとしたパケットが確実に相手に転送される」と言う意味ではありません。そんな保証はどこにもありませんし誰も保証してくれません。

「確実なパケット転送」の本当の意味は「転送を試みた後に『転送成功』と言われたパケットは、パケットの内容が元と違ってたり化けてたり欠落していたりせずデータが正しいのは保証する。だが『転送失敗』と言った場合は『失敗したのは保証する』けども、その他は一切保証しない。データの中身もどうなってるか判らない」と言う意味です。

つまり「転送を試みたら失敗と言われた」とか「転送を試みたらいつまで経っても転送が終らず、結果待ちしてるうちに接続が切れる」と言う事もある、と言う事です。

これもやっぱり「TCPエラーやTCPタイムアウトに対してソフトウェアがどういう挙動を取るか」の問題になります。

この回答への補足

回答ありがとうございます。

ダウンローダーは「正常終了」になっています。
ということは

・パケットはきちんと送られているが、パケットを結合するクライアントソフト側に問題がある。
・パケットの転送失敗とTCPではなっているが、クライアントソフトがエラーをスルーしてしまう?などクライアントソフトの仕様に問題がある。

ということでよろしいのでしょうか。

補足日時:2006/03/31 13:46
    • good
    • 0

FTPにはいくつかの転送モードがありますが、一番使われているのは、ファイルをそのままTCPで送り、TCP接続を閉じることによってファイル末を示すというものです。


この場合、何らかのトラブルでデータ転送のTCP接続が途中終了してしまった場合と最後まで転送し終わって接続をクローズした場合とが区別できない事があります。結果として、正常終了したのに尻切れトンボのファイルがクライアント側に残る、と思います。
詳しくはFTPのRFCを読んでください。
    • good
    • 0

ブラウザでのFTP転送に失敗しているのなら、始めからそう書いた方がよくありませんか?


またブラウザ搭載のダウンローダー?なら、そのダウンローダー名とバージョンも必要でしょう。

サーバー上にあるファイルは破損していない事が大前提ですが、その確認はとれていますか?
UDPで転送しているのなら兎も角、TCPで転送しているのに破損してしまうのはchie65536さんが書いたように、ソフトウェアが起因している可能性大です。

普通のブラウザでFTP接続してDLしてみましたか?

この回答への補足

ブラウザ搭載以外にも専用ソフトでも経験しています。

補足日時:2006/07/03 11:38
    • good
    • 0

問題の切り分けが出来ていません。



FTPは「ファイルのアップロードやダウンロードが途中で中断され完了しないで終り、転送先に尻切れになったファイルが作られる事もある」と言う前提で設計されています。

その為、一部のFTPサーバーには「中断した転送を再開するオプション」があります。

あくまでも、これは「FTPのプロトコルがそういう風に設計されている」のが原因で、TCPとかは無関係の話です。

TCPが保証しているのは「確実なファイル転送」ではなくて「確実なパケット転送」な筈です。

もちろん、パケットのビット欠落が起きればちゃんと再送制御が行われますし、接続が切れない限りは相手に「パケットが」確実に届きます。

ですので、FTPサーバーソフトやFTPクライアントソフトがファイルを幾つものパケットに分割して転送する際、1つ1つのパケットがパケット単位で確実に転送されるのがTCPにより保証されます。

しかし、全部のパケットが全部キッチリ正しい順番で転送されるかどうかは、TCPにとっては「俺はそんなの知ったこっちゃない。俺にパケット転送依頼してる上位のソフトウェアに文句言え」なのです。

「全部のパケットが全部キッチリ転送されて、転送されたパケットが正しい順番になって、ローカルディスクにちゃんとセーブされて、正しいファイル名が付く」かどうかは、FTPサーバーソフトとFTPクライアントソフトが保証すべき問題であり、ストレートに言えば「ソフトウェアの問題」です。
    • good
    • 0

TCP接続を行っていたとしても、パケットの欠落はありますよ。


TCPプロトコルはデータの抜けや重複、送信側で送ったデータがそのままの順序で正しく受信側へ届くという“信頼性”があるだけで“完全”ではありません。

確かに送信側から受信側へ正しく届かなかった場合は再送する事になっていますが、その再送もうまくいかず結果的に破損した状態になってしまう事があります。

結局はネットワークの状態に因るところが大きいです。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。

ブラウザ搭載のダウンローダによりおこなっていますが、
「正常終了」しているのに「ファイル破損」状態になってしまいます。
これは「正常終了」とするクライアントソフト側の問題であり、TCP側は転送エラーのようなものを出力して終わり。
というイメージでよろしいでしょうか。

お礼日時:2006/03/31 13:43

いくつ物要因がありますが


よくある要因のひとつとして
ファイルをDL中になんらかの理由で
タイムアウトを起こしたとします。
(回線の混雑だったりサーバがこけたり
いろいろな要因で)
そのようなファイルは壊れたファイルになりますよね。

この回答への補足

回答ありがとうございます。

ファイルは正常終了で生成されている(例えばlzh)が、
解凍するとファイル破損になる。
という状況なのですが

回答者様が言われている「タイムアウト」は
「パケット一つ一つ」の「タイムアウト」ということでよろしいでしょうか。

他回答者さまのをみると、その場合、タイムアウトと表示するのはクライアントソフト次第ということでしょうか。

補足日時:2006/03/31 13:35
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!