我意识到这个问题可能对某些人来说不够具体。然后，答案可能会为某些人提供一些帮助。
这是我的问题的根源：我想要一个高性能服务。我担心在服务器或客户端上的任何一种服务方法中花费太多时间。我知道我收到IO完成端口的通知，我不知道我的方法可以或应该花多长时间。我担心我需要将传入的调用卸载到某种背景文件Q上并处理不在IO线程上的传入方法。我已经看到了一千个关于如何使用WCF的“简单”示例，以及至少100个如何使用WCF并且没有死锁Windows UI线程的示例，但老实说，没有描述此过程的“现实生活”。
问题：
对于超高性能WCF服务，当用户可以保证他们知道自己在做什么时，在服务本身中，将来电中继到后台队列，以释放IO是“常见的”吗？完成端口线程，如果它是常见的，是必要和/或重要的，或者IO完成端口是否有自己的排队机制，我不必要的老派，偏执，造成更多麻烦？例如，如果服务方法可能需要10秒才能完成（上帝保佑），这可以吗？我知道我可以写一个异步方法，但这会打开第二个蠕虫病毒，下面将进一步介绍。
背景：
我打算关闭任何WCF锁定（并发模式=多个）。我的沟通渠道是TCP/NET和full duplex。我正在写的服务将是一个“视频引擎”，用户可以告诉服务器启动和停止作业，查询状态/状态，偶尔服务器会通知客户端元数据和帧位置/等。视频服务器服务除了是普通的WCF服务之外，还将拥有自己的线程，并且会抽取视频并偶尔通知用户正在发生的事情。
关注1：
假设我有一个“StopJob”方法可以停止复杂的视频作业。作为用户，我希望该方法，当我在代理上调用它时，阻止直到作业实际停止，但是在服务器上使用的底层引擎需要很长时间才能停止，因为使用了一些异步转换需要很长时间才能杀死。假设我希望它阻止并且不关心我的UI。在服务中，我得到Stop方法，然后......等待10秒（或更长时间）。这个可以吗？如果我将它卸载到后台线程，我需要在我的回调接口中添加一个方法，并在停止实际发生时通知用户，或者我需要将该方法编写为异步方法。这两件事都吓到了我。
关注2：
对于需要很长时间的操作，代理可以使用异步方法生成（其过程在我找到的任何地方都没有很好地描述），但看起来更容易的是简单地添加一些“事件”回调接口的方法，并在完成长任务时调用它们。这故意避免使用任务＆lt;＆gt;和其他“漂亮”的.NET东西，但它在我眼中也更简单。 “大多数”人如何处理这个问题？我正在评论部分寻找评论。
关注3：
始终建议将回调写为“单向”，这样他们就不会尝试回复服务器并发生死锁。我可以用一种方式编写它们并跳过使服务器重入，或者我可以用一种方式编写它们并使服务器重入。我假设“大多数”时间，从服务器到客户端的回调通常不会将信息返回给服务器？！因为如果是这样，无论如何都不能单向使用。我还没有看到很多使用回调和重入服务器的例子......任何人都有一个好的链接？