私は、パートナーの1人に雇われた下請け業者からの着信マルチメディアコンテンツのゲートキーパーとして機能するカスタムftpクライアントを作成しています。ローカルでファイルをディスクに書き込む前にファイルの内容を解析できるため、twistedを選択しました。とにかく、twistedを探索する機会を探していました。'twisted.protocols.ftp.FTPClient.retrieveFile'を使用してファイルを取得し、エスケープされたパスをファイルに渡し、プロトコルを'retrieveFile'メソッドに渡します。コールバックのイベントハンドラーがファイルをローカルでディスクに書き込んでから、ftpサーバーからリモートファイルを削除するため、ファイル全体が取得されたことを絶対に確認したいです。クライアント。私の質問は、私は本当にこれについて心配する必要があるのかということです、
質問する
1007 次
1 に答える
4
この領域での動作については、いくつかの単体テストがあります。
twisted.test.test_ftp.FTPClientTestCase.test_failedRETR最も直接関連するものです。これは、ファイル転送の進行中に制御およびデータ接続が失われた場合を対象としています。
この領域のテストカバレッジは大幅に改善される可能性があるように思われます。たとえば、転送の進行中にデータ接続だけが失われた場合をカバーするテストはありません。ただし、これをトリッキーにする1つの点は、FTPはそれほど堅牢なプロトコルではないということです。ファイル転送の終了は、データ接続が閉じることによって通知されます。安全のために、受信する予定のバイト数を受信したかどうかを確認する必要があります。このチェックを実行する唯一の方法は、事前にファイルサイズを知るか、LIST（FTPClient.list）を使用してサーバーにファイルサイズを要求することです。
これらすべてを考慮すると、ファイル転送が完了したら、常にサーバーに取得する必要のあるバイト数を尋ね、プロトコルに配信されるバイト数と一致することを確認することをお勧めします。Deferredから返されたときにエラーバックがretrieveFile発生する場合がありますが、そうでない場合でも安全に保つことができます。
于 2009-11-18T17:52:09.630 に答える