基本的な .NET 非同期ソケット サーバーにファイル共有機能を追加しています。クライアントに送信してもらいたいペイロードは、headers+commandID+binaryFileData だけです。このサーバーは、.NET クライアントに加えて、VB6 クライアントからの要求を処理する必要があります。
VB6 クライアントの担当者は、ファイルを転送するための複雑な方法を考え出しましたが、それには特に感銘を受けませんでした。ファイルの小さなブロックを送信し、最後にサーバーが次のブロックを要求します。このパーティは、大きなサイズで送信しようとすると、VB6 Winsock コントロールがうまく機能しないと主張しています (「大きな」とは、小さくないことを意味します。1MB は「大きな」という意味です)。これはばかげているように思えます。
クライアントが単一の大きなペイロードをソケットに書き込み、サーバー側でメッセージの再構築/ハッシュを実行するだけです。VB6 の Winsock 制御で大規模な書き込みに問題があるのは事実ですか、それとも相手が言い訳をしているのでしょうか?
いいえ、Winsock とソケット コントロールには、ファイルやサイズの概念はなく、バイト ストリームだけです。バッファサイズに達していると思います。その場合、すべてが送信されるまでチャンクで送信する必要があります。サーバーが次のチャンクを要求する必要はありません。これにより、処理が遅くなります。
VB6が大きな（大きな値の小さな値の）ペイロードに問題があるという主張は絶対に真実です。さらに、結果として生じる問題は、設置ごとに、また月の満ち欠けによって異なります。VB6 winsock コントロールに 1 MB 以上を送信すると、問題が発生します。そこにいた、それをした、ただ私を信じてください。
とはいえ、私たちは別の道をたどりました。関数は任意のサイズのペイロードを受け入れ、それをメガバイト単位でチャンクアップしてキューに入れます。winsock コントロール イベント ( SendCompleteIIRC) は、次のメガバイトをデキューするために使用されます。
これは、消費側のアプリ (単一の呼び出し、ペイロード サイズに関係なく) に対して透過的であり、送信側で問題が回避されます。これは、洗練されたプロトコルがなくても確実に機能します。問題は完全にクライアント内にあります。