インターネットを介して、ある PC (クライアント) から別の PC (サーバー) に大きなバイナリ (2Gb-10Gb) データを送信する必要があります。最初に、wsHttpBinding バインディングとメッセージ セキュリティを使用して、IIS でホストされている WCF サービスを使用しようとしましたが、時間がかかり (数日)、私には不適切でした。ここで、ソケットを使用してクライアントおよびサーバー アプリケーションを作成することについて考えます。それはより速いでしょうか？
それを行う最良の方法は何ですか？
ありがとう
この場合、私にとっては普通の古い FTP が適しています。これを使用すると、ジョブを最初からやり直す必要なく、中断された転送を回復する機会が得られます。非常に大量のダウンロードが何らかの理由で中断される可能性を考慮に入れる必要があります。
大量のデータを送信する場合、接続の帯域幅によって制限されます。また、接続の中断に注意する必要があります。大量のデータを再送信する必要がある場合、小さな中断が大きな影響を与える可能性があります。
BITSを使用できます。これにより、データがバックグラウンドで転送され、データがブロックに分割されます。そのため、多くのことを処理してくれます。
IIS (サーバー上) に依存し、データを転送するためのクライアント (API) があります。したがって、データを転送するデータの基本を読み書きする必要はありません。
高速になるかどうかはわかりませんが、少なくとも単一の HTTP または FTP リクエストを作成する場合と比べてはるかに信頼性が高くなります。そして、あなたはそれを非常に速く走らせることができます。
帯域幅に問題があり、インターネット経由で送信する必要がない場合は、宅配便で DVD を送信するなど、高帯域幅/低遅延の接続を確認できます。
.Net から BITS を使用できます。CodeProject には wrapper があります。
通常、この種のことのために既に書かれているものを活用するのが最も適切です。例：FTP、SCP、rsync など
FTP は、ダウンロードが中断した場合の再開をサポートしていますが、アップロードの再開をサポートしているかどうかは不明です。Rsyncは、この種のことではるかに優れています。
編集：私があまりよく知らないものを検討する価値があるかもしれませんが、別のオプションかもしれません-bit-torrent?
さらなるオプションは、UDT などのプロトコル ライブラリを使用して独自のクライアント/サーバーをロールすることです。これにより、TCP よりも優れたパフォーマンスが得られます。参照: http://udt.sourceforge.net/
まあ、帯域幅はあなたの問題です.WCFオーバーヘッドは長いバイナリ応答であまり機能しないため、ソケットにさらに低くしてもあまり役に立ちません. おそらくあなたのオプションは、ロスレスストリーミング圧縮アルゴリズムを使用することですか? データが圧縮可能であれば (zip を使用して予行演習を行います。ローカル ディスク上のファイルを圧縮する場合は、適切なストリーミング アルゴリズムを見つけることができます)。ところで、履歴書のサポートを提供することをお勧めします:)
より高いレベルのフレームワークに関連する帯域幅のオーバーヘッドはいくらかありますが、ストリームとしての WCF ファイル転送は十分に高速であることがわかりました。通常、SMB 経由の通常のファイル転送と同じくらい高速です。セッションで数十万の小さなファイルを転送しましたが、これには 6 ～ 10 GB の大きなファイルが含まれることもありました。まともな接続で大きな問題が発生したことは一度もありません。
私はそれが提供するインターフェースが本当に好きです。リモート処理やデュプレックスエンドポイントなど、FTP ではできない非常に優れた機能を実行できます。両側で接続のあらゆる側面をプログラムで制御でき、ファイルとともにメッセージを通信できます。楽しいもの。
はい、FTP は高速でシンプルです。