2

次のように、いくつかの小さなフィールドと 1 つの大きな Xml 文字列を含むオブジェクトを WCF 経由で送受信する必要があります。

[DataContract]
public class ServiceResponse
{
    [DataMember]
    public int Id { get; set;}

    [DataMember]
    public string Xml {get; set;}
}

HTTP ベースのバインドを使用する必要がありますが、サービスは内部であるため、コントラクト dll は共有されます。Xml 文字列は数 MB に達する可能性があります。このサービスでは、クライアント マシンを介してサーバー間でデータを転送できるため、最初のクライアント呼び出しで Xml の大きな塊を取得し、それをローカル ディスクに保存し、次に 2 回目の呼び出しでデータをディスクから別のボックスの別のサービス インスタンスに転送します。 . したがって、クライアントは文字通りデータを保存して転送し、ロジックや処理はまったくありません。

これらのオブジェクトを送信するための最も効率的なメカニズム、つまりペイロードが小さく高速なメカニズムが必要です。

いくつかの質問:

  • ペイロードで Xml の大きなチャンクを送信する最も効率的な方法は何ですか?
  • MemoryStreama を使用してネットワーク経由で送信する前にオブジェクトを a にシリアル化し、サービス操作で型をパラメーターとしてBinaryFormatter使用する利点はありますか?Stream
  • 数 MB のメッセージの場合、Streamed転送モードを使用すると違いはありますか?

Protobuf-net のようなサードパーティのライブラリは使用できません (残念ながら)。

アドバイスよろしくお願いします...

4

3 に答える 3

2

XmlNodeまず、文字列ではなくとして送信します。

[DataMember]
public XmlNode Xml {get; set;}

これにより、XML タグのすべてのエンコードが回避されます。

于 2013-02-26T08:18:20.450 に答える
1

データの転送 = サーバーでの準備時間 + 転送時間 + クライアントでの処理時間。

乗り換え時間はかなりのものだと思います。以前、XML にシリアル化し、結果の文字列を zip 圧縮してから、バイト配列を送信するか、zip 圧縮された文字列を base64 にシリアル化することで、この問題を解決できました。

処理時間が追加されますが、圧縮されていないバージョンの転送時間ほどではありません。

問題のアプリが起動時にキャッシュするためのスタンディング/起動データは、圧縮されていない数メガバイトであり、世界中で使用されているため、低品質の接続エリアでは圧縮が必要です..

于 2013-02-26T08:28:15.230 に答える
0

あなたの声明

BinaryFormatter を使用してネットワーク経由で送信する前にオブジェクトを MemoryStream にシリアル化し、サービス操作のパラメーターとして Stream 型を使用する利点はありますか?

を実際に送信する必要はXmlなく、現在シリアライズされているオブジェクトを送信する必要があることを意味しますXml

その場合、BinaryFormatter ではなくProtocol Buffersを使用して、最速のシリアル化と最適な圧縮を実現できます。

詳細と比較については、

https://stackoverflow.com/a/11550778/141172

アップデート

ServiceResponseBinaryFormatter を使用したシリアル化について言及していた場合でも、Protocol Buffers は優れたパフォーマンスを提供します。

于 2013-02-25T21:49:13.907 に答える