2

現在、当社の製品の 1 つにある FTP アップロード機能に関する顧客の問題をデバッグしようとしています。この機能により、顧客はファイル (< 1MB) を中央の FTP サーバーにアップロードして、さらに処理することができます。FTP クライアント コードは、VB.NET で社内で作成されました。

顧客は、300KB から 500KB の範囲のファイルをアップロードしようとすると、「接続がリモート ホストによって強制的に閉じられました」というエラーが表示されると報告しています。ただし、社内でこれをはるかに大きなファイル (比較的言えば)、つまり 3MB 以上でテストしましたが、このエラーは発生しませんでした。クライアントが同じ FTP ログオン資格情報を使用して接続するのと同じ FTP サーバーにアップロードしました。唯一の違いは、オフィスから行ったことです。

TCP プロトコルにはフロー制御が組み込まれていることを知っているので、1 回の Send 呼び出しで送信されるデータの量は問題にならないはずです。プロトコルは、サーバーの内部制限に合わせてそれ自体を調整するためです (私の記憶が正しければ. ..)

したがって、私が考えることができる唯一のことは、クライアントとルーターの間の中間ホストがクライアントを人為的にレート制限し、クライアントを切断していることです (512 バイトのチャンクでループ内のファイル データを送信します)。

これは、データを送信するために使用されるループです (buffer は、ファイル データを含むバイト配列です)。

            For i = 0 To buffer.Length - 1 Step 512
                mDataSocket.Send(buffer, i, 512, SocketFlags.None)
                OnTransferStatus(i, buffer.Length)
            Next

お客様の ISP (またはお客様のファイアウォール) が、クライアント コードが一定時間内に送信できるデータ量に人為的なレート制限を課している可能性はありますか? もしそうなら、この状況を処理する最善の方法は何ですか? 明らかな解決策は、ソケット レベルでこれを行う方法がない限り、送信ループに遅延を導入することだと思います。

ISP がクライアント接続を強制終了することでレート制限違反を処理するというのは、私には非常に奇妙に思えます。TCP/IP の内部フロー制御/スロットリング メカニズムに依存しないのはなぜですか?

4

5 に答える 5

2

Comcast と BitTorrent を検索します。ここに1 つの記事があります。

于 2008-09-29T22:07:05.913 に答える
1

最近の 500k は恐ろしく小さいので、それほど小さいものをスロットルすると少し驚かれることでしょう。

すでにリクエストをチャンク化していることは承知していますが、データが転送されているかどうかを判断できますか? コードは常に同じループ ポイントで失敗しますか? FTP サーバーのログを確認できますか? スタック トレース全体についてはどうでしょうか。ISP に連絡して、どのようなポリシーを持っているか尋ねてみましたか?

とはいえ、一部のデータが通過すると仮定すると、ISP にはトラフィック シェーピングがあり、x バイトが書き込まれた後にルールが適用されると考えられます。データ > x で、データが送信される前にソケットのタイムアウトが期限切れになり、例外がスローされる可能性があります。

ftp クライアントはデータ転送用に別の接続を作成しますが、サーバーが制御接続が閉じていることを検出すると、通常はデータ転送接続を強制終了することに注意してください。したがって、もう 1 つ確認することは、制御接続がまだ有効であることを確認することです。

最後に、ftp サーバーは通常、再開可能な転送をサポートしているため、他のすべての解決策が失敗した場合は、失敗した転送を再開することが最も簡単な解決策になる可能性があります。

于 2008-09-29T22:55:11.897 に答える
1

問題の切り分けを試みます。

  • お客様が同じファイルを別のサーバーにアップロードできるようにします。クライアントの FTP クライアントに問題がある可能性があります。
  • クライアントからファイルを取得し、クライアントに自分でアップロードして、問題を再現できるかどうかを確認します。

最終的に、3MB のファイルが正常に動作する場合でも、500KB のファイルが動作する保証はありません。これは、問題が状態に依存し、ファイル転送の終了中に発生する可能性があるためです。

于 2008-09-29T22:09:53.113 に答える
1

はい、ISP は適切と思われるパケットに制限を課すことができます (ただし、倫理的には問題があります)。たとえば、私の ISP は、ハードウェアが盗み出す P2P トラフィックを問題なくカットしています。これはトラフィック シェーピングと呼ばれます。

ただし、FTP トラフィックの場合、これはほとんどありませんが、わかりません。問題は、トラフィックシェーピングでソケットをドロップすることはなく、パケットのみをドロップすることです。tcp プロトコルは各ピア側で処理されるため、間にあるすべてのパケットをドロップでき、ソケットは存続します。場合によっては、コンピュータの 1 つがクラッシュしても、ソケットを使用しない限り、ソケットは生きたままになります。

クライアント側のファイアウォール/プロキシ構成が悪いことが最善の策だと思います。ここでより良い説明。

それか、クライアント インストールのルーターまたはケーブルに障害があるか、正しく構成されていないかのいずれかです。

于 2008-09-29T22:24:10.770 に答える
0

ISP が 500KB のファイル転送を強制終了しようとは思わない。私はソケット関連の専門家でも ISP の専門家でもありません。

于 2008-09-29T21:54:45.160 に答える