WCF Duplex 客户端的最佳实践
我不能否认双工异步调用的性能优势，但有些事情让我感到谨慎。
我担心的是，给定一个实例化的客户端对象，WCF 是否能够知道哪个特定的客户端服务实例将接收回调参数？
谁能告诉我这是否是一个好主意？如果不是为什么不呢？
new DuplexChannelFactory<IServerWithCallback>(
new ClientService(),
new NetTcpBinding(),
new EndpointAddress("net.tcp://localhost:1234/"+Guid.NewGuid()))
如果上面的虚拟路径是保留的，怎么能丢弃呢。我希望客户服务生命周期相当短。 IE 发出请求并接收响应，接收完成后将其终止。与将客户端服务的生命周期集中起来并保持更长的生命周期相比，缩短客户端服务的生命周期会带来多么严重的性能损失。
这个想法是为了避免超时问题。完成接收、发送后，尽快处理。按照惯例 - 不能传递客户服务。如果您需要信息，请创建一个新的，简单 - 就像 EF/L2S 等一样。
从 WCF 服务本身内部，如何终止与客户端的会话。 IE。我不希望客户端结束会话 - 我知道我可以相应地装饰我的操作，但我希望服务在满足某些条件时以编程方式终止自身。
我可以附加端口并相应地转发以解决任何防火墙问题，但我担心的是客户端是否位于负载平衡器后面。该服务如何知道要调用哪个特定服务器？
I can't deny the performance benefit of a duplex async call, but some things about makes me feel wary.
My concern is that given a client object instantiated, will WCF be able to tell which particular client service instance will receive the callback argument?
Can anyone tell me if this is a good idea? If not why not?
new DuplexChannelFactory<IServerWithCallback>(
new ClientService(),
new NetTcpBinding(),
new EndpointAddress("net.tcp://localhost:1234/"+Guid.NewGuid()))
If the virtual path above is reserved how can it be discarded. I want the client service lifetime to be fairly short. IE make a request and receive a response and when done receiving, kill it. How bad is the performance penalty in making the client service lifetime short as opposed to pooling it and keeping it alive longer.
The idea is to avoid timeout issue. When done receiving, sending, dispose ASAP. By convention - can't pass the client services around. If you need info, create a new one, simple - just like EF/L2S etc.
From inside the WCF service itself, how do I kill the session with the client. ie. I don't want the client ending the session - I know I can decorate my operation accordingly, but I want the service to terminate itself programmatically when certain conditions are met.
I can affix the port and forward accordingly to resolve any firewall issue, but what I'm worried about is if the client were to sit behind a load-balancer. How would the service know which particular server to call?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为最终 Duplex 服务只是 Microsoft 的另一个失败的架构。这是纸面上看起来非常好的东西之一，但经过仔细检查后就会分崩离析。
缺点太多：
1）服务器依赖session建立客户端监听。这是存储在内存中的会话信息。因此服务器本身无法实现负载平衡。或者，如果它是负载平衡的，您需要打开 ip 关联性，但现在如果其中一台服务器受到轰炸，您不能简单地添加另一台服务器并期望所有这些会话自动迁移到新服务器。
2) 对于位于路由器/防火墙/负载均衡器后面的每个客户端，需要创建一个具有特定端口的新端点。否则路由器将无法正确地将回调消息路由到适当的客户端。另一种方法是使用允许自定义编程将特定路径重定向到特定服务器的路由器。又是一个艰巨的任务。或者另一种方法是让具有回调的客户端托管自己的数据库并通过数据库共享数据<--可能在许可费用不是问题的某些情况下工作......但它引入了很多复杂性，因此很繁重在客户端上加上它将应用程序和服务层混合在一起（在某些特殊情况下这可能是可以接受的，但除了巨大的设置成本之外）
3）所有这些基本上表明双工实际上是无用的。如果您需要回调，那么您最好在客户端设置一个 wcf 主机。它将变得更简单并且更具可扩展性。另外，客户端和服务器之间的耦合也更少。
可扩展架构的最佳双工解决方案是最终不使用双工解决方案。
I think in the end Duplex services is simply another failed architecture from Microsoft. This is one of those things that looked really good on paper but just falls apart upon closer examination.
There are too many weaknesses:
1) Reliance on session to establish client listener by the server. This is session information is stored in memory. Hence the server itself cannot be load balanced. Or if it were load balanced you need to turn ip affinity on, but now if one of the servers is bombarded you can't simply add another one and expect all these sessions to automagically migrate over to the new server.
2) For each client sitting behind a router/firewall/loadbalancer, a new end point with specific port needs to be created. Otherwise the router will not be able to properly route the callback messages to the appropriate client. An alternative is to have a router that allows custom programming to redirect specific path to a particular server. Again a tall order. Or another way is for the client with the callback to host its own database and share data via a database <-- Might work in some situation where licensing fees is not an issue... but it introduces a lot of complexity and so onerous on the client plus it mixes the application and services layer together (which might be acceptable in some exceptional situation, but not on top of the huge setup cost)
3) All this basically says that duplex is practically useless. If you need call back then you will do well to setup a wcf host on the client end. It will be simpler and much more scalable. Plus there is less coupling between client and server.
The best duplex solution for scalable architecture is in the end not using one.
这将取决于您需要新客户的时间有多短以及他们将持续多长时间。如果您每次都特别需要一个新客户端，那么池就不是一个选择，但如果客户端继续做同样的事情，为什么不让它们等待使用，如果它们再次出错重新创建相同的客户端。
实际上，在回调场景中，如果服务回调客户端（真正调用客户端上的函数）以传递信息，则服务现在是客户端，反之亦然。您可以使用使回调 .Close() 连接的服务，但它会一直打开，直到 GC 可以处理它为止，根据我的经验，这可能需要比预期更长的时间。 ，客户端应该负责自行关闭或断开连接（客户端是调用某些内容的客户端），服务应该只返回答案或从客户端获取数据。
在双工回调中，现在回调客户端的服务将获取在 duplexchannelfactory 后面抽象的客户端地址。如果服务无法回调给客户端，我认为没有什么可以做的，你必须确保你的客户端调用服务的端口是开放的，以便接收我猜的回调。
It will depend on how short you need the clients new'd up and how long they will last. Pooling would not be an option if you specifically need a new client each time, but if the clients keep doing the same thing why not have a pool of them waiting to be used, if they fault out recreate that same client again.
In reality in a callback scenario if the service is calling back to the client (really calling a function on the client) to pass information the service is now the client and vice versa. You can have the service that's making the callback .Close() the connection but it will be open until the GC can dispose of it, from my experience that can take longer than expected. So in short the client should be responsible (the client being the one making the call to something) for shutting itself down, or disconnecting, the service should only give back answers or take data from a client.
In duplex callbacks the service now calling back to the client will get the address of the client abstracted behind the duplexchannelfactory. If the service can't call back to the client I don't think there's much that can be done, you'd have to ensure the port that your clients are calling to the service is open to receive callbacks I would guess.