サーバーからファイルをダウンロードするアプリケーションがあります。接続が非常に不安定であるため、ファイルが正しくダウンロードされていないかどうかを確認し、それに応じて管理できるように、ファイルの整合性をチェックする機能を実装しています。
このプロセスはどのようにすればよいですか？今、私はファイルのハッシュをサーバーに要求し、次にファイル自体に別の要求を行い、ダウンロードしたファイルのハッシュを計算し、2つのハッシュをファイル比較します。
これは正しいアプローチですか？何かがそうではないと私に言います。ハッシュが異なることがわかった場合は、ハッシュを再度要求することを含め、まったく同じプロセスを数回実行します（これは同じである必要があります）。毎回わざわざハッシュを要求する必要がありますか？正しく転送されない場合に備えてやっていますか？これは不要ですか？リクエストは高価で、現在は非常に遅いので、リクエストの数を減らす方法はありますか？
何か案は？
サーバーがC＃を使用していて、クライアントがAndroidデバイス（JAVA）であることが重要な場合に備えて、
ありがとう、
TCP/IP は独自に整合性チェックを行います。する必要はありません。各データ パケットの整合性は CRC で保証され、TCP プロトコルは失われたパケットをチェックして再送信を要求します。したがって、サーバーが Content-Length ヘッダーを生成している限り、誤送信が検出され、クライアントがエラーになることを確認できます。
つまり、ファイル ハッシュに適した場所は、カスタム HTTP ヘッダーです。その名前の前に「X-」を付けて、既存または将来の標準ヘッダーと衝突しないようにします。
はい、もっと良い方法があります。まず、ファイル全体のハッシュを要求する代わりに、ファイルを圧縮し、圧縮されたデータを (たとえば) 100KB のブロックに分割し、ブロックごとに 1 つの一連のハッシュを提供し、その後にそれらの一連のハッシュの自己ハッシュを提供します。自己ハッシュとは、ハッシュのベクトルを取得し、それをハッシュして、ベクトルの最後に貼り付けることを意味します。
自己ハッシュをチェックすることで、このハッシュのベクトルが正しく転送されたことを確認できます。パスしない場合は、ハッシュ ベクトルを再要求します。
次に、圧縮データの転送を要求します。これが発生すると、転送が正しいことを 100KB 間隔で確認し、エラーが発生するとすぐに中止できます。次に、(可能であれば) 中断したところから再リクエストを開始します (「満潮マーク」)。
最後に、データを安全に解凍できます。多くの解凍アルゴリズムは、さらなる整合性チェックを実行します。これにより、プログラミングのミスから防御するためのさらなる検証ラウンドが得られます。無料チェックはそれだけの価値があります。
このアプローチは、TCP/IP のようなチェックされたプロトコルまたは UDP のような信頼できないプロトコルで作業しているかどうかに関係なく機能します。まだ行っていない場合は、データを圧縮することも大幅な改善になります。
唯一の欠点は、明らかに作業量が増えることです。