为了克服Azure负载均衡器上的（明显的）4分钟空闲连接超时，似乎有必要一次又一次地将一些数据沿管道发送到客户端，以防止连接被视为空闲。 / p>
我们的控制器设置为AsyncController，它会在其他对象上触发几个不同的异步方法，所有这些方法都设置为使用IO完成端口。因此，我们立即从我们的方法返回，并且当处理完成数据包时，IIS挂钩回原始请求，以便我们可以呈现我们的视图。
在这种情况下，有没有办法定期向网络发送几个字节？在“经典”情况下，我们可以执行该方法，然后在我们等待时旋转，每隔几秒发送一次数据，直到异步方法完成。但是，在这种情况下，IIS线程被释放去做其他业务，我们在完成回调中挂钩回到它。该怎么办？这可能吗？
答案 0 :(得分：0)
虽然您的特定案例涉及特定于Windows Azure（LB的4分钟超时），但问题仍然是纯IIS / ASP.NET工作方式。无论如何，我不认为在AsyncController / AsyncPage中向客户端发送“ping-backs”是不可能的。这是AsyncPages / Controllers的全部概念。 IIS将套接字放在一边，让线程服务于其他请求。只有在使用AsyncManager.OutstandingOperations.Decrement（）时将OutstandingOperations设置为零时才返回;只有这样才会返回控制权以向客户端发送最终响应。一旦你成为发送回应的重点，就没有回头路了。
我宁愿争论为什么有人会等待4分钟才能得到回应的建筑方法（即使有一个好的动画“请等待”）？在此期间可能会发生很多事情。从浏览器崩溃，通过互联网中断到客户端的总功率损耗/中断。如果您正在使用真正的Azure，为什么不通过队列（Azure存储队列或服务总线队列）发送工作者角色的任务。对于如此长时间运行的任务而言，在您面前的另一个选择是使用SingalR和完全AJAXed解决方案。通过SignalR与长时间运行状态进行通信的地方。
由于评论而更新1
除了@knightpfhor建议的方法之外，这也可以通过队列来实现。请求者创建具有某个唯一ID的任务，并将其发送到“任务提交队列”。然后“侦听”（或定期/不定期地轮询）具有给定任务ID的消息的“任务完成”队列。
在任何情况下，我都没有看到在长时间运行的任务的整个持续时间内保持客户端连接的原因。有很多方法可以解除这种沟通。