如何使用 WCF 确定传出消息的优先级
我希望能够对 WCF 服务的传出数据/消息进行优先级排序。
这是基本场景：
- 客户端向服务器请求数据流。数据流是实时的、大量的并且可能是无止境的（设备监控数据）。我们将其称为 HighPriorityDataStream。
- 客户请求附加数据。我们将其称为 LowPriorityData。
带宽是有限的（想想拨号调制解调器或卫星）。当请求 LowPriorityData 时，当前的 HigPriorityDataStream 不会被中断或延迟，这一点非常重要。
我已经有一个基于套接字的遗留系统，这是通过手动控制数据放入套接字缓冲区的顺序来完成的。高优先级数据被放置在缓冲区中，如果还有剩余空间，则添加较低优先级数据以填充缓冲区的其余部分。
我正在尝试使用 WCF 重新设计这个流程...我不知道任何开箱即用的解决方案，并且我认为我可能需要编写自定义通道行为，但我想借鉴在我走那条路之前先了解一下社区:)
I would like to be able to prioritize the outgoing data/messages from a WCF service.
Here's the basic scenario:
- Client requests from server a data stream. The data stream is live, large, and potentially unending (equipment monitoring data). We'll call this HighPriorityDataStream.
- Client requests additional data. We'll call this LowPriorityData.
The bandwidth is limited (think dial-up modem or satellite). It is very important that the current HigPriorityDataStream not be interrupted or delayed when a request for LowPriorityData is made.
I have a sockets-based legacy system already where this is accomplished by manually controlling the order that data is placed into the socket buffer. High-priority data is placed in the buffer, and if there's room left over, lower priority data is added to fill the rest of the buffer.
I'm trying to reengineer this process with WCF... I don't know of any out-of-the box solutions and am thinking I may need to write a custom channel behavior, but I'd like to pick the brains of the community before I go that route :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为没有通用的开箱即用的解决方案。该解决方案取决于您的其他要求。您想控制每个客户端或整个服务器（所有客户端）的带宽吗？您想从同一代理调用低优先级操作还是为新操作启动新代理？您想同时运行更多高优先级操作吗？您想优先考虑传入的请求吗？
最简单的解决方案期望您控制每个客户端的带宽，为所有调用重复使用相同的代理，同时只能完成一个高优先级操作，并且请求按 FIFO 顺序处理。您只需使用 [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession, ConcurrencyMode = ConcurrencyMode.Single)] 标记您的服务实现（这应该是通过 NET.TCP 公开的服务的默认设置）。此设置将为来自同一客户端代理的所有调用重用相同的服务实例，但一次只会处理一个调用（其他调用将在队列中等待，直到处理完毕或超时）。
此致，
拉季斯拉夫
I think there is no general out-of-the box solution. The solution is dependend on your other requirements. Do you want to control bandwith per client or per whole server (all clients)? Do you want to call low priority operation from the same proxy or do you start new proxy for new operation? Do you want to run more high priority operations at the same time? Do you want to prioritize incomming requests?
The easiest solution expects that you control bandwith per client, you are reusing same proxy for all calls, only one high priority operation can be completed at the same time and requests are processed in FIFO order. Than you just mark your service implementation with [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession, ConcurrencyMode = ConcurrencyMode.Single)] (this should be default setting for services exposed over NET.TCP). This settings will reuse the same service instance for all calls from the same client proxy but only one call will be processed at time (other will wait in queue until they are processed or time outed).
Best regards,
Ladislav
经过大量研究（感谢拉迪斯拉夫的深思熟虑的想法），我得出的结论是，我要求通信层解决业务层问题。为了更好地说明问题，有多个连接和一个数据源。数据源必须优先考虑从自己的数据源（实时数据流和持久数据库）收集的数据，并根据优先级将数据发送回各个客户端。需要明确的是，客户端具有基于其基于角色的身份的相对优先级，数据源具有优先级（优先选择实时数据而不是持久数据），数据源中的各个字段具有优先级顺序（其他条件相同，字段X 必须始终在字段 Y 之前发送。
这都是严格的业务逻辑，我们采用的解决方案是一组优先级队列，它根据这些优先级要求自动对输入数据项进行排序，然后按该顺序服务每个请求。
After a lot of poking around (thanks Ladislav for your thoughtful ideas), I've come to the conclusion that I'm asking the communication layer to solve a buisness-layer problem. To better state the problem, there are multiple connections and one data source. The datasource must prioritize which data it gathers from it's own data sources (live data streams and also persisted databases) and send the data back to the various clients based on their priority. To be clear, the clients have a relative priority based on their role-based identity, the data sources have a priority (prefer live data over persisted data) and individual fields within a data source have a priority order (all else being equal, field X must always be sent before field Y).
This is all firmly business-logic and the solution we adopted as a set of priority queues that autoamatically sorted the input data items based on these priority requirements and then served each request in that order.