通过 WCF 发送大型 Xml 字符串的最有效解决方案？

Question

我需要通过 WCF 发送和接收包含几个小字段和一个大 Xml 字符串的对象，如下所示：

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

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

我必须使用基于 Http 的绑定，但服务是内部的，因此合同 dll 将被共享。 Xml 字符串可能达到几 MB。该服务允许通过客户端机器在服务器之间传输数据，因此第一个客户端调用检索一大块 Xml，将其保存到本地磁盘，然后第二个调用将数据从磁盘传输到其他地方某个其他盒子上的另一个服务实例.所以客户端从字面上保存数据并转发它，根本没有逻辑或处理。

我需要最有效的机制——即有效负载小、速度快——来发送这些对象。

一些问题：

• 在有效负载中发送大量 Xml 的最有效方法是什么？
• 将对象序列化为MemoryStream，然后使用BinaryFormatter 通过网络发送，然后使用Stream 类型作为服务操作中的参数，是否有任何优势？
• 对于几 MB 的消息，使用 Streamed 传输模式有什么不同吗？

我不能使用像 Protobuf-net 这样的第三方库（很遗憾）。

感谢任何建议......

Answer 1

首先，我会将其作为XmlNode 而不是字符串发送：

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

这避免了所有 XML 标签的编码。

Answer 2

数据传输=服务器准备时间+传输时间+客户端处理时间。

我猜传输时间相当长。我之前通过序列化为 XML、zip 压缩生成的字符串、然后发送字节数组或将 zip 压缩的字符串序列化到 base64 来解决这个问题。

它增加了处理时间，但远不及未压缩版本的传输时间。

有问题的应用程序在启动时缓存的站立/启动数据是数兆字节未压缩，在世界各地使用，因此在质量较低的连接区域，压缩是必要的。..

Answer 3

你的陈述

在使用 BinaryFormatter 通过线路发送之前将对象序列化为 MemoryStream 有什么好处，然后在服务操作中使用 Stream 类型作为参数？

表示您实际上不需要发送Xml，而是当前序列化为Xml 的对象。

如果是这样，您将使用Protocol Buffers 而不是 BinaryFormatter 获得最快的序列化和最佳压缩。

有关更多信息和比较，请参阅

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

更新

如果您指的是使用 BinaryFormatter 序列化 ServiceResponse，Protocol Buffers 仍将提供卓越的性能。