1

indy コンポーネントを使用してリモート サーバーからアップデートをダウンロードするアプリケーションを開発しました。問題は、FTP サーバーがダウンしているか、IP アドレスが正しくない場合、idFTP.connect() が結果を返すのに時間がかかりすぎることです (接続失敗)。

接続応答を高速化する最善の方法は何ですか、または idFTP に接続する前に IP アドレスを確認することである可能性があります。

前もって感謝します。

4

3 に答える 3

2

ReadTimeout プロパティを設定する必要があります。デフォルトでは 1 分に設定されています。

于 2013-01-16T09:01:39.707 に答える
2

デフォルトでは、Indy クライアントは、接続が成功したかどうかを OS が報告するまで待機します。はい、OS が DNS を使用してホスト名を検索し、ネットワーク チェックを行い、ネットワーク遅延に対処する必要がある場合は、時間がかかる可能性があります。それほど長く待ちたくない場合は、Indyで のTimeoutパラメーターを使用できます。 Connect()9 以前、またはConnectTimeoutIndy 10 のプロパティを使用して、待機時間を短縮します。 ただし、サーバーIPが決定された後の実際のソケット接続試行にのみ適用されます。プロパティを IP 以外のホスト名に設定するHostと、Indy は OS に DNS ルックアップを実行してホスト名の IP を取得するように要求しますが、Connect()そのルックアップにかかる時間を制御するために使用できるロジックはありません。それだけの制御が必要な場合は、TIdDNSResolverHostを呼び出す前にIP を手動で取得し、それをプロパティに割り当てConnect()ます。

于 2013-01-17T01:50:30.280 に答える
1

まあ、ネイティブの connect() API のタイムアウトは、設計上、長いことで有名です (モデムのような待ち時間の長いリンクに対応するため)。人為的にタイムアウトを短くすると、失敗の通知が早まる可能性があります (ただし、多くの開発者はモデムを見たことがないため、今日ではそれほど問題ではありません:)。

FTP は、2 つの TCP 接続と、おそらく DNS ルックアップを必要とするかなり複雑な転送です。これらのどれもが、長い接続遅延を引き起こす可能性があります。TidFTP には、継承された 'ReadTimeout' プロパティと、タイムアウト パラメータを持つ connect() オーバーロードがありますが、それらがどれほど効果的かはわかりません。

歴史的に、私は常に TTimer などを使用して自分でそのような操作をタイムアウトさせてきました-FTP スレッドが適切なシグナルで応答しない場合 (たとえば、TThread.Sychronize またはユーザー定義の Windows メッセージ SendMessage() が GUI に送信されます)、やがて、「FTP 失敗」アクションが実行され、応答を無視して自己終了するように指示するフラグが FTP スレッドに設定されます。PostMessage を使用しないでください。使用すると、TTimer が起動している間、ポストされた応答がキューに入れられる小さな時間枠ができます (競合)。

ああ、TidFTP をフォームにぶつけて (または TForm.FormCreate で作成して) メインの GUI スレッドから実行しようとしている (TidAntiFreeze の有無にかかわらず) 場合は、それをやめてスレッドをオフにしますFTP.

于 2013-01-16T11:29:12.283 に答える