来自HTTP/REST服务的进度通知

Question

我正在开发一个Web应用程序,它将任务提交给主/工作系统,该系统将任务分配给一系列工作器实例中的任何一个.工作队列主服务器作为单独的进程运行(在一台单独的机器上),任务通过HTTP/REST请求提交给主服务器.将任务提交到工作队列后,客户端应用程序可以提交另一个HTTP请求以获取有关任务的状态信息.

对于我的Web应用程序,我希望它提供某种进度条视图,为用户提供有关任务处理进度的指示.实现这一点的显而易见的方法是使用AJAX进度计小部件,该小部件定期轮询工作队列以查找已提交任务的状态.我的问题是,如果没有频繁的民意调查,有没有更好的方法来实现这一目标？

我已经考虑过让客户端Web应用程序打开一个服务器套接字,它可以监听来自工作主机的通知.我的另一个类似想法是使用XMPP或类似的协议进行状态通知.(当然,主/工作系统需要更新以提供通知,但我拥有代码,因此可以自己进行任何必要的更新.)

有关建立这样的通知系统的最佳方法的任何想法？额外的努力是值得的,还是简单的轮询解决方案？

Answer 1

轮询

客户端不断轮询服务器以获取响应的状态.

优点

• 真正的RESTful意味着可缓存和可扩展.

缺点

• 如果您不想过多地轮询服务器,则不是最佳响应.

持续连接

在响应完成之前,服务器不会关闭与客户端的HTTP连接.服务器可以使用HTTP多部分通过此连接发送中间状态.

Comet是实现此行为的最着名的框架.

优点

• 最佳响应速度,几乎来自服务器的实时通知.

缺点

• 连接限制在Web服务器上受到限制,保持连接打开时间过长可能最多加载服务器,最糟糕的是打开服务器进行拒绝服务攻击.

客户端作为服务器

使服务器发布状态更新和对客户端的响应,就像它是另一个RESTful应用程序一样.

优点

• 无论是在服务器上还是在客户端,都不会浪费任何资源等待响应.

缺点

• 您需要在客户端上提供完整的HTTP服务器和Web应用程序堆栈
• 具有默认"根本没有传入连接"的防火墙和路由器将受到阻碍.

随意编辑以添加您的想法或新方法!

Answer 2

我想这取决于几个因素

• 反馈的准确性如何（1％，5％，50％）
  准确的反馈使其值得追求某种进度条和彗星样式推动力。如果您只能说“忙碌...请稍等...快要完成了”，那么简单的ajax“我们就在那里了”调查肯定更容易编写代码。
• 客户必须多久才能看到“完成”消息
• 每个任务花费多长时间（1秒，10秒，10分钟）
  1秒，使它显得有些无聊。10秒值得。10分钟意味着您最好建议用户去喝咖啡休息一下:-)
• 将会有多少个并发请求
  除非您拥有“特殊”服务器，否则实时推送样式的系统会吞噬连接，并且很快就会使您筋疲力尽。不得不投入更多的Web服务器来获得花哨的进度条可能会损害预算。

我在871184上有一些示例代码，该示例代码显示了手动滚动的“ 永远帧 ”，效果似乎很好。我开发的项目为此付出了不小的努力，但操作需要花费几秒钟，我们可以给出非常准确的百分比。该代码使用asp.net和jquery，但是常规技术将适用于任何服务器和javascript框架。

编辑正如约翰指出，状态可能报告不是RESTful服务的工作。但是，没有什么可以说您无法在客户端上打开连接到轮询该服务的服务器页面的iframe。理论上说，服务器和服务之间至少会更近一些：-)