2017-07-12 16 views
0

私たちのサーバからファイルをダウンロードしようとしているidFTP Indyコンポーネントに問題があります。それはファイルの99%をダウンロードし、次にハングアップします。 GETステートメントは返されません。最近変更されたのは、win 8.1を実行しているデスクトップからwin10を実行しているラップトップに移動したことだけです。進行状況とファイルサイズの合計を画面に書き込むと、最後まですぐにダウンロードされ、最後のバイトは終了しません。ダウンロードしようとしているファイルは15,573,350バイトです。約14MB(むしろ速い)に達して停止します。私は別のファイルをダウンロードしようとしましたが、それは同じことです。Delphi XE6内でダウンロード完了後にGET()文が返されない

アイデア?

ここにコードがありますが、それについては何も気にしません。私はそれを主なプロジェクトの中にあるものかどうかを見極めるために、私たちの働くアプリからそれをコピーして試してみました。

with IdFTP1 do 
    begin 
    Host := 'xxx'; 
    Username := 'xxx'; 
    Password := 'xxx'; 
    passive := True; 
    Connect; 
    ChangeDir('Service_Update'); 
    ChangeDir('QA'); 
    Self.Caption := Size('jam.zipper').tostring; 
    TransferType := ftBinary; //tried with and without 
    Get('jam.zipper','jam.zipper',true); 
    Button1.Caption := 'Done'; //never gets here 
    end; 

答えて

0

Get()は、説明したようにフリーズする方法はたくさんあります。いくつかの方法は次のとおりです。

  1. サーバが最後に転送接続優雅を閉じていない、または転送が終了した後、サーバーがコマンド接続上で、最終的なFTP応答メッセージを送信していません。確認のためにパケットスニファを使用してください。これを処理するには、コマンドと転送の両方の接続で無限無限ReadTimeoutを割り当ててみてください。

  2. FTPセッションがFTP対応ではないルータ/ファイアウォールを通過する場合、コマンド接続は長時間の転送中にタイムアウトして削除される可能性があります。これを処理するには、TIdFTPには、転送中にコマンド接続でTCPキープアライブを設定するためのNATKeepAliveプロパティがあります。

  3. TIdFTPをUIコントロールの非同期呼び出しを行うイベントハンドラを持つワーカースレッドで使用している場合、デッドロックを含むすべての種類の問題が発生する可能性があります。常にUIへのアクセスを同期します。

+0

ありがとうレミー。私が気になるのは、サーバーに変更がないということです。ダウンロード機能は常​​に機能しています。これは、今や勝利10になったらそれ以上はないことを発見するまでです。これが違いを生むかもしれないと思いますか? ポイント3では、実際にスレッドを使用しています。しかし、私の実際の作業コードは、私がここで共有したデモと同じように動作します。それはすばやくすべてをダウンロードして、最後には何もしません。 –

+0

OK、間違っていました。私はこれを再テストするために8.1を獲得するために復帰した、そしてそれは同じ問題です。サーバー側で何かが変更されたことを意味する必要があります。 –

関連する問題