5

さまざまなサイズ（数バイトから数百MBまで）の数千のファイルを送信する.NETリモーティングクライアント/サーバーを構築しています。これを実現するための最良の方法についてフィードバックをお願いします。私が見ているように、いくつかのオプションがあります。

  • ファイル全体をリモーティングオブジェクトにシリアル化し、サイズに関係なく一度に送信します。これはおそらく最速ですが、送信中に障害が発生すると、ファイル全体を再送信する必要があり、再開する方法はありません。
  • ファイルサイズが小さいもの（4KBなど）よりも大きい場合は、4KBのチャンクに分割し、それらをリモートにして、サーバーで再アセンブルします。これの複雑さに加えて、継続的なラウンドトリップと確認応答のために遅くなりますが、1つのピースの障害は多くの時間を無駄にしません。
  • FTPまたはSFTPサーバーのようなものをアプリケーションに含める-クライアントはサーバーにリモート処理の使用を開始していることを通知し、ファイルをアップロードしてから、リモート処理を使用して完了を通知します。個別のFTPサービスを必要とするのではなく、アプリにすべてを含めたいのですが、必要に応じてこのオプションを利用できます。
  • 障害を処理するために構築された、またはある種のチェックポイント/再開を実行できる、ある種の指定されたTCP接続またはWPFまたはその他の伝送方法を使用します。
  • 私が行方不明になっている他のものはありますか？

最も柔軟で信頼性の高い伝送方法は何ですか？速度についてはそれほど心配していませんが、信頼性についてはもっと心配しています。ファイルが遅くても移動したいのです。クライアントとサーバーはマルチスレッドになるので、接続が許せば同時に複数のファイルを送信できます。

フィードバックをありがとうございます-私は人々がこれを達成する方法についていくつかの推奨事項を得るために賞金を投入します。

4

3 に答える 3

4

BITS（バックグラウンドインテリジェント転送サービス）は優れたソリューションです。長年の経験が組み込まれています

いくつかの出発点は

于 2010-03-31T21:55:04.540 に答える
1

calmhは、OSIレイヤー4の側面からあなたが尋ねている質問に答えますが、私はあなたがあなたの質問のアプリケーション層をもっと見ているように感じます。TCPは、ネットワーク側の遅延、送信ウィンドウなど、あらゆるものを確実に処理します。ただし、ユーザーがダウンロードセッションを途中で終了し、後で中断したところから再開することを決定した場合にどうなるかを直接判断することはできません。

別の角度から質問に答えるには、速度に関係なく、ファイルをセクションにチャンクし、すべての接続に対してインデックスを付けることを強くお勧めします。ファイル全体がダウンロードされたら、クライアントで再度アセンブルできます。これにより、ユーザーはダウンロードセッションを一時停止して再開できます。

速度を決定する限り、これを行うために事前に構築されたメソッドがあるかもしれませんが、使用できる1つの方法は、独自の速度テストを構築することです。クライアントに1 MBを送信し（アップロード）、受信したら応答を送信します。1100をクライアントから応答を返すのにかかった時間で割った値は、クライアントがサーバーからダウンロードするのにかかるKB/sです。クライアントからのアップロードをテストするには、その逆も同様です。

送信に関しては、既存の技術を利用することをお勧めします。 SFTPは、認証された暗号化されたデータ転送をサポートします。基本的にはFTPですが、SSH経由です。これと対話するためにどこかで利用可能なAPIがあるはずです。

ちなみに、私はあなたが話しているほどのことは何もしていませんが、私のアイデアが少なくとも考慮すべきいくつかのオプションを提供してくれることを願っています。

于 2010-03-30T22:21:40.020 に答える
0

これは、TCP自体が作成され、数十年またはハードテスト中に調整されたものです。リモーティングは、大きなファイル転送ではなく、小さなRPC呼び出しに対して行われます。データの送信にはTCPソケットを使用するだけで、下位層のプロトコルに遅延、送信ウィンドウ、MTUなどを心配させる必要があります。

于 2010-03-29T16:19:52.933 に答える