我正在尝试确定构建WCF服务的最佳方法,而我最挣扎的领域是返回对象列表。
64k的内置maxMessageSize看起来相当高,而且我真的不想提高它(快速谷歌搜索发现100个地方撞击maxMessageSize达到数千兆字节范围似乎是愚蠢的)。但是,当我返回一组对象(约150个项目)时,我超过了默认的64k。
我几乎要回到我自己的类继承IEnumerable并具有hasNext,hasPrevious和PageSize的属性,以便我可以在客户端实现分页 - 这看起来像很多代码。另一个选择是增加maxMessageSize并希望获得最佳效果,但这感觉不对。
我服务的所有其他方面都很有效,它只是在我遇到问题时返回了大量的收藏品。
对于后台,此服务有两种类型的使用者,UI应用程序主要是web和/或wpf应用程序,数据处理应用程序,.NET控制台应用程序,以及其他一些非UI应用程序。对于UI应用程序,我希望让它们保持响应并保持messageSize低,在控制台应用程序上它并不重要,因为它们只是将数据拉下来进行处理并将其推回到服务。
答案 0 :(得分:3)
我认为maxMessageSize的默认值太低的原因是为了降低DoS攻击的风险。
如果响应消息很大,则客户端配置需要增加maxMessageSize。对于客户而言,DoS不太可能存在风险,因此将其增加到非常大的值是安全的。
但这并非“顶起maxMessageSize并希望最好” - 您应该考虑您的应用程序的预期最大大小,考虑您是否决定使用分页,并对其进行适当配置。 / p>
在服务器上,maxMessageSize需要足够大才能获得允许的最大请求消息。这里的DoS可能是一个问题,但在某些环境(例如Intranet)中,使用非常大的值可能是安全的。
如果您的服务正在公开允许客户端查询潜在大型数据集的操作,则另一种分页方法是定义客户端在一次调用中可以请求的最大项目数。
例如,您可能有一项操作允许客户请求货币列表和一系列日期的汇率:
public IList<ExchangeRate> GetExchangeRates(string baseCurrency, IList<string> currencies, DateTime startDate, DateTime endDate);
然后,您可以设置服务返回的结果数量限制,并将其公开给客户:
public int GetMaximumResultCount();
然后,客户需要查询GetMaximumResultCount
,并确保:
(endDate - startDate).TotalDays * currencies.Count < maximumResultCount
如果客户端不遵守此规则,则服务器会抛出合适的FaultException
答案 1 :(得分:0)
您可以使用 MTOM消息包含。当发送大数据时,它是Stream的替代品。这是一个配置示例:
<system.serviceModel>
…
<bindings>
<wsHttpBinding>
<binding name="ExampleBinding" messageEncoding="Mtom"/>
</wsHttpBinding>
</bindings>
…
<system.serviceModel>
只需在绑定配置上将 messageEncoding 属性设置为Mtom。另外,更改 maxReceivedMessageSize 和 maxBufferSize 。
How To here和更多信息link text