0

httpを介した.Netリモーティングでは、SerilizationInfo.AddValue（SerializationInfoValueName、（（MemoryStream）writer.BaseStream）.GetBuffer（）、typeof（byte []））呼び出しを実行して、byte[]をクライアントに返します。

ただし、byte []サイズが大きくなりすぎて、OutOfMemory例外が発生する場合があります。唯一の救済策は、何らかの形のチャンクを利用することのようです。WCFへの移行は最も論理的であるように思われますが、近い将来、それは不可能になります。

では、一般的なチャンクソリューションを実装する方法について何か提案はありますか？

4

3 に答える 3

1

これを行うためのより安全な方法は、サーバーから返すオブジェクトのストリームをリモートすることです。StreamはMarshalByRefObjectを拡張するため、クライアントに送信されるオブジェクトに開いているStreamへの参照（たとえば、送信するファイルデータまたはバッファーを指す）を含めると、メソッドを呼び出すときにクライアントがサーバーにコールバックします。ストリームプロキシ上。このようにして、クライアントは（理由の範囲内で）必要なバッファサイズを使用してデータを移動できます。

于 2009-12-28T22:25:17.303 に答える
0

組み込みのチャンクはありません。自分で実装する必要があります。それはかなり簡単なはずです。

次のようないくつかのインターフェースでうまくいくはずです。

Guid GetFile(string filename);
Guid GetFile(string filename, out int chunkCount);
byte[] GetFileChunk(Guid id, int chunkIndex);

が呼び出されると、サーバーはキーとして機能するに対してGetFile()ファイルを「キャッシュ」できます。次に、これをクライアントに返して、ファイルの実際のチャンクをダウンロードするようにさらに要求できるようにします。Dictionary<>GuidGuid

GetFileChunk()チャンクインデックスがそのGUID/ファイルのチャンクの数を超える場合は、nullを返す必要があります。

あなた次第の場合、チャンクのサイズ。応答性とパフォーマンスのどちらかを選択できます。チャンクが大きいほど、パフォーマンスが向上します。ただし、GUIでプログレスバーなどを更新する場合は、もちろん「応答性」に悪影響があります。何が最も効果的かを試してみてください。

別のインターフェースは次のようなものです。

Guid GetFile(string filename, out ulong numOfBytes);
byte[] GetFileData(Guid id, ulong index, ulong count);

これは、クライアントがダウンロードしたいチャンクのサイズを決定できることを意味します。そして、ある種のスケーリング戦略を実装することができます。

于 2009-12-28T22:20:51.013 に答える
0

解決策は、サーバーのリソースが簡単に「検索可能」であるかどうかに大きく依存します。たとえば、ファイルにアクセスしてその内容を返すだけの単純なリモーティングサービスを作成する場合、それは非常に単純なものになります。取得するデータの目的のオフセットと長さをクライアントに渡すだけです。

ただし、サーバー上でデータを生成するのがより複雑で、1回の論理呼び出しで呼び出しを完了する必要がある場合は、カスタムシンクなどを詳しく調べる必要があります。

.NETリモーティングを使用してから非常に長い時間が経ちましたが、StreamはMarshalByRefObjectから派生しているため、クライアントを参照することでストリームを返すことができる場合があります。ただし、論理演算よりも有効期間が長いサーバー側オブジェクトを使用しているため、スケーラビリティの問題が発生する可能性があり、後でアップグレードする場合はWCFに直接類似していないため、これは注意が必要です。

WCFは、組み込みのプロトコルを介してデータをストリーミングするためのネイティブサポートを備えています。

于 2009-12-28T22:24:43.737 に答える