【发布时间】:2010-05-07 16:02:46
【问题描述】:
我正在尝试确定构建 WCF 服务的最佳方法,而我最苦恼的领域是返回对象列表。
64k 的内置 maxMessageSize 似乎相当高,我真的不想提高它(快速谷歌搜索发现有 100 个地方将 maxMessageSize 提高到数 GB 范围,这似乎很愚蠢)。但是,当我返回一个对象集合(约 150 个项目)时,我超过了默认的 64k。
我几乎要返回我自己的类,该类继承 IEnumerable 并具有 hasNext、hasPrevious 和 PageSize 的属性,以便我可以在客户端实现分页——这似乎是很多代码。另一种选择是提升 maxMessageSize 并希望获得最好的结果,但这感觉不对。
我的服务的所有其他方面都运行良好,只是返回了我遇到问题的大量收藏。
作为背景,此服务有两种类型的消费者,UI 应用程序主要是 Web 和/或 wpf 应用程序,以及数据处理应用程序、.NET 控制台应用程序,可能还有其他一些非 UI 应用程序。对于 UI 应用程序,我想让它们保持响应并保持低消息大小,在控制台应用程序上这并不重要,因为它们只是将数据拉下来进行处理并将其推送回服务。
【问题讨论】:
-
为什么增加 maxMessageSize 是愚蠢的?它实际上要么增加大小,要么分块发送。我不会一一要求。如果调用是异步的,UI 仍然可以响应大型集合。
-
我猜愚蠢是一个不好的词选择,但我的意思是默认值的存在是有原因的,当我需要更改默认值时,我总是尝试退后一步,尤其是当我不需要时完全理解为什么默认是这样的。
-
Bross:默认消息大小为 64K,以避免拒绝服务攻击。想象一下,例如2 GB - 攻击者可以用 2 GB 消息淹没您的服务,从而压倒您可能拥有的任何硬件。拒绝任何大于 64K 的消息是不可能的(或至少不太可能)
-
那么合理的大小是多少,因为 64k 似乎对于我处理的相对适中的数据大小来说应该绰绰有余,但我一直遇到这个限制是一个问题。