WCF中的Keep-Alive是否使用了比轮询更多的资源？

Question

我可能会设置几个测试床应用程序并找出答案，但我希望有人已经体验过这个或者只是简单地了解一下。我有三个可执行文件。两个不同的客户端（称为Client1.exe和Client2.exe）和一个WCF服务主机（称为Host.exe），它承载两个客户端或多或少的消息总线类型服务。我不会进入“为什么”，因为这是一个长篇故事而且对这个问题没有用处。

重点是，Client1通过此服务向Client2发送请求。 Client2执行操作，然后将结果响应给Client1。 Client1将始终是请求的发起者，因此这种操作顺序将始终以这种方式保持一致。这也意味着Client1可以打开它的通道，根据需要与该服务进行通信，而由于需要回调服务，Client2必须保持其通道畅通。我开始尝试保持活力。但是，这些都是台式机和PC睡眠事件中的三个，或者其他问题（不确定）似乎会干扰它。一旦它超时，一切都必须重新启动，这使它成为一个真正的痛苦。我有一些想法，我可能会尝试帮助保持活着的方法，但这提出了一个问题，我没有答案...这是我的资源的最好用途。

我认为，Client2有两种主要方法，

1. 通过大量监控（定时器和检查连接状态）和连接重置代码保持活跃，因为它可以立即响应请求，因此更快。不利的一面是，在用户将Client2保持在桌面上打开的时候，必须保持这种状态，这可能是短暂的，可能是疯狂的。
2. 定期轮询一个请求，该请求允许仅在检查或处理来自Client1的请求时使用资源。这将是较慢的，因为轮询请求不是实时的，但将消除任何外部问题关于断开服务。这也会导致我必须向服务添加更多状态。它已经是一个PerSession服务，其中包含Client2 ID的可用实例列表，以便Client1知道它正在与哪个实例通信，但它会添加更多。

Client2执行许多其他功能，因此仍然必须非常高效地使用此过程，这让我想知道哪个最有可能耗费资源？投票方法的资源成本更高吗？或者试图保持活力？