c# - 是否强制执行 WCF 数据流限制？

Question

我们一直在客户站点看到随机的 OutOfMemoryExceptions 和 InsufficientMemoryExceptions。我们使用 GZipMessageEncoder 来压缩消息。 (我知道 IIS 7.x compression 选项和 other problems with buffering and/or the GZipMessageEncoder 。)

我想尝试启用 WCF 流。我们的 WCF 服务具有如下契约(Contract):

[OperationContract]     
DataSet GetDataSet(Guid someGUID, string someName, DataSet parameters);

根据 this article on MSDN :

Operations that occur across a streamed transport can have a contract with at most one input or output parameter

显然，我们的契约(Contract)违反了 WCF 流限制。该合约有 3 个输入参数。

但是，出于好奇，我还是决定尝试启用流式传输。我编辑了 web.config 文件和 MyCSharpClient.config 文件，并将以下属性插入到绑定(bind)的传输部分:

<httpTransport ... transferMode="Streamed">

令我惊讶的是，一切似乎都正常!没有抛出异常。我可以进入 GZipMessageEncoder 并验证调用的是流方法而不是缓冲区方法。

那么，我的问题是:为什么我能够在违反 WCF 对输入参数的限制的操作上下文中设置流式传输？考虑到 MSDN 流媒体文章的措辞强硬，我认为这只是一个实现细节，我不能依赖这种行为。

Answer 1

当前发生的情况如下:您在 HTTP 传输上启用了流式传输，因此传输不会缓冲任何内容 - 传输接收到一个 Message 对象，并将其写出到传输流(包装在 XML 编写器中)直接。但是，操作的参数在序列化之前会被缓冲，因此您“支付”了传输模式设置为“缓冲”时的内存使用量。在网络上，区别在于来自此服务的响应将被分块(而不是具有 Content-Length header )(即，它将具有 Transfer-Encoded: chunked header ，并且body 将被相应地格式化。但它也同样有效。

我想说 MSDN 中的文章可以选择更好的词。为了让操作利用流，它需要有一个参数，通常是Stream、Message 或某种类型实现 IXmlSerializable。但是一个简单的合约(即 [OperationContract] int Add(int x, int y))也同样有效。而且我想它会继续这样工作，因为对于一个单一的契约(Contract)来说，具有“正常”操作和利用流的操作是完全有效的，并且因为需要为每个端点设置传输模式(和不是每个操作)，它也必须适用于“简单”操作。