wcf - 在具有消息安全性的 WCF 中使用 wsHttp 传输大量数据负载(序列化对象)

Question

我有一个案例，我需要使用 wsHttp 使用 WCF 传输大量序列化对象图(通过 NetDataContractSerializer )。我正在使用消息安全性并希望继续这样做。使用这个设置，我想传输序列化对象图，它有时可以接近 300MB 左右，但是当我尝试这样做时，我开始看到 System.InsufficientMemoryException 类型的异常出现。

经过一些研究，在 WCF 中，默认情况下，服务调用的结果包含在一条消息中，该消息包含序列化数据，并且该数据默认在服务器上缓冲，直到整个消息被完全写入。因此，由于该缓冲区已满，服务器正在耗尽允许分配的内存资源，从而导致内存异常。我遇到的两个主要建议是使用流或分块来解决这个问题，但是我不清楚这涉及什么以及我当前的设置(wsHttp/NetDataContractSerializer/Message Security)是否可以使用这两种解决方案。到目前为止，我知道使用流消息安全是行不通的，因为消息加密和解密需要对整个数据集而不是部分消息起作用。然而，分块听起来可能是可能的，但是我不清楚如何使用我列出的其他约束来完成。如果有人可以就可用的解决方案以及如何实现它提供一些指导，我将不胜感激。

我应该补充一点，在我的情况下，我真的不担心与其他客户端的互操作性，因为我们拥有和控制通信的每一方，并使用共享接口(interface)模式将数据传输到任何一方。因此，我对任何符合使用 wsHttp 和消息安全性来传输使用 NetDataContractSerializer 序列化的对象图的限制的想法持开放态度，我更喜欢一种无需彻底更改现有服务和周围基础设施的解决方案。

相关资源:

Chunking Channel

How to: Enable Streaming

Large attachments over WCF

Custom Message Encoder

Another spotting of InsufficientMemoryException

Non-Duplex Chunking Channel needed

Streaming large content with WCF and deferred execution

我也对可以对这些数据进行的任何类型的压缩感兴趣，但是一旦我可以过渡到 .NET 4.0，我可能最好在传输级别执行此操作，以便客户端将自动支持 gzip标题，如果我理解正确的话。

更新 (2010-06-29):

关于我如何得出缓冲消息太大导致我的问题的结论的一些历史。最初我在测试时看到了下面的 CommunicationException。

基础连接已关闭:连接意外关闭。

最终在运行它并进行更多日志记录后，我发现了导致指定消息出现问题的底层 InsufficientMemoryException 异常。

无法分配 268435456 字节的托管内存缓冲区。可用内存量可能较低。

其起源于以下方法。

System.ServiceModel.Diagnostics.Utility.AllocateByteArray(Int32 大小)

因此，换句话说，失败来自分配数组。将相同的数据序列化到磁盘时，它会占用大约 146MB，如果我将其减半，那么我就不会再收到错误消息，但是我没有深入研究破坏缓冲区的特定阈值，以及它是否特定于我的系统或不是。

更新 (2010-12-06):

我想此时我正在寻找以下一些澄清。我的理解是，默认情况下，WCF wsHttp 具有消息安全性，整个消息(通常是我返回的整个数据集)需要在响应发送回客户端之前在服务器上缓冲，从而导致我的问题。

可能的解决方案:

限制数据大小 - 通过使用某种形式的压缩、编码或限制使用某种类似分页的方法返回的实际数据，以避免消耗传出缓冲区的最大容量。

流 - 允许以流方式通过 WCF 发送大量数据，但这与 wsHttp 或 MessageSecurity 不兼容，因为这些技术需要缓冲所有数据。

分块 channel - 允许将数据分解为单独的消息，但此时我不确定这对服务契约(Contract)设计的限制以及我是否仍然可以将 wsHttp 与消息绑定(bind)一起使用。

限制我可以返回的数据只能在一定程度上起作用，并且与 Streaming 选项一样，这些选项需要对 WCF 服务调用之外的许多较低级别的工作进行编码。所以我想我需要知道的是，分块 channel 的任何可能实现是否可以通过允许将一组数据分解为服务器上的单独消息，然后在客户端上拼凑在一起来避免大消息问题这样我就不必更改现有服务契约(Contract)的接口(interface)/形状，并且在仍然使用消息安全性和 wsHttp 的同时，该过程对每个服务实现的客户端和服务器部分几乎是隐藏的。如果分块 channel 将要求我重新编写我的服务契约(Contract)以公开流，那么我看不出这与 Streaming 解决方案有什么不同。如果有人可以简单地为我回答这些问题，我将奖励他们并将其标记为答案。

Answer 1

protobuf-net 一般有一个 重要 大多数数据节省空间(如:数量级)，并且可以附加到 WCF。不幸的是目前 它不支持完整的图，只支持树。但是，我在那里有一些计划，但我根本没有时间实现。我不能保证任何事情，但我可以尝试早点完成这项工作。

除此以外;可能有一些方法可以调整您现有的代码以使用树而不是图形。