12

私は 10 台の新しい PC を受け取りましたが、すべて (おそらく) Windows 7 Pro が新しくインストールされており、他に何も行われていません。

ネットワークにIndy 10コンポーネントを使用して、Delphi XE2でコーディングされたプログラムがあります。TIdTcpCleint の「接続タイムアウト」および「読み取りタイムアウト」プロパティを 500 ミリ秒に設定し、「ソケットの再利用」を「o/s 依存」に設定しました」(No に設定してビルドも試しました)、「Nagle を使用」のままにしました。 （Trueに設定されているものは何でも（falseでも試しました）。

ここに問題があります: これらの PC で同じ .EXE を実行し、ネットワーク ケーブルを引っ張るケースをテストすると、デバッグ トレースは、接続試行/接続タイムアウトが同じ秒または次の秒 (粒度 1) で発生していることを示します。 2 番目) - しかし、接続タイムアウトが表示されるまでに 20 秒または 21 秒かかるものもあります。

AP がインストールされていないように見えますが、主張されているように PC が完全に「新規インストール」されていないように見えるものもあります。誰かが何かをインストールしてから削除したのかもしれませんし、パフォーマンスを微調整しようとしたのかもしれません。

10 台の PC に Windows を再インストールする前に、どこを見ればよいか教えてもらえますか? TCP クライアントの接続タイムアウトに関して、20 (または 21) 秒でベルが鳴りますか?

[更新] 特定の IP アドレスに直接接続しようとしているので、DNS をチェックするという @Nikolai の提案が適切かどうかわかりません。これについては最初に言及しなかったことをお詫びします。

[更新] プログラムはソケットを開いたままにしようとしません。新しいデータごとに、接続、データの送信、および切断を繰り返します。

4

2 に答える 2

7

悲しいことに、これは意図したとおりに機能しています。接続はすでにタイムアウトしました。Indy は、あなたが要求した 500 ミリ秒以内に接続が失敗すると判断しました。ただし、それは関数が を返すことを保証するものではありません。

接続がタイムアウトすると、Indy は接続をスピンダウンしてすべてのリソースを解放します。これは同期的に行われます。つまり、基礎となる TCP 操作が失敗するのを待つことになります。通常、これには 20 秒かかります。

解決策は、スレッドで connect を呼び出すことです。信じられないかもしれませんが、これは Indy が既にタイムアウトを実装するために行っていることです。ただし、スレッドの待機がタイムアウトになると、メイン スレッドで接続をシャットダウンしようとします。それをワーカースレッドに任せる必要があります。

一部のシステムではすぐに発生し、他のシステムでは 20 秒で発生する理由については、正確なネットワーク構成によって異なります。たとえば、IPv6 が有効になっている場合、スタックは IPv6 から IPv4 への接続を使用しようとする可能性があり、物理インターフェイスがダウンしていてもダウンを報告しない場合があります。接続不能の即時検出は保証されていないため、それに頼るべきではありません。

于 2012-09-04T11:21:38.827 に答える
1

私は過去にINDYで同じ問題を抱えていました（D6を使用している間、1998年から2000年）。コンポーネントをIP*Worksに変更しました。当時は外付け部品でしたが、私が知る限りXE2に含まれています。Ip * Worksは最初は少し理解しにくいですが、コミュニケーション構造へのアプローチ方法は大きく異なります。

試してみる価値はあると思います。

于 2012-09-06T12:21:59.153 に答える