服务器推送技术的 API 模型 (COMET)

发布于 2024-07-30 02:48:31 字数 1113 浏览 3 评论 0原文

我想向 CppCMS 添加服务器端事件的支持。 我了解如何操作的技术部分 通信级别:客户端发送长轮询XmlHTTPRequest,并等待响应, 服务器接受连接并且不响应,直到服务器端事件发生并发送 对客户端的响应。 客户端重复该过程。

然而,对于大多数 Web 开发人员来说,这太“低”了。 有很多问题:如何管理事件、如何管理连接等等。

我考虑了两种可能的模型:

  1. 定义了一些命名事件和服务器端, 例如“134号聊天室有新消息”; 当请求接受时,服务器端应用程序检查消息 在房间中(例如在数据库中)并且如果没有给客户端的新消息 它订阅事件并等待它。

    当其他客户端将数据发送到服务器时,它会通知服务器上的所有应用程序 “134 号聊天室有新消息”事件,他们醒来并发送这些消息 给客户等等。

    这个模型看起来仍然是相当“低级”的模型,但它隐藏了所有 通知方法。

  2. 另一个选择是定义一些命名队列,这样每个客户端都会创建这样的队列 连接到服务器后排队并等待新消息。 当有的客户 向“Chat Room no 134”发布一条新消息,在服务器端广播该消息 到连接到此“134 号聊天室”的所有队列,并且消息被传递 给客户。

    但是,出现了许多问题:

    • 如何在单页面级别管理队列和会话级别?
    • 如何删除队列并为其设置超时?
    • 如果多个“窗口”订阅同一个队列,会发生什么情况?
  3. 在服务器端创建一个持久对象,用于粘合服务器端事件 和用户端事件。 它可以通过不同的 XHR 请求进行通信 重定向到它。

    因此客户端(JavaScript)注册事件并使用 XHR 等待它们 和服务器端分派事件通知,直到页面重建。

所以,我想知道什么是最受欢迎和推荐的 服务器端推送技术背后的 API 模型?

谢谢

编辑:添加了第三个选项

I'm whiling to add a support of Server Side events to CppCMS. I understand the technical part of what to do on the
level of communication: Client sends long polling XmlHTTPRequest, and waits for respond,
server accepts the connection and does not respond until server side event occurs and sends
the response to the client. The client repeats the procedure.

However, this is too "low" level for most of web developers. There are many questions: how do I manage events, how do I manage connections and so on.

I thought about two possible models:

  1. There are some named events defined and the server side,
    for example "New Message in Chat Room no 134";
    when the request accepted the server side application checks the messages
    in the room (for example in DB) and if there is no new messages for the client
    it subscribes to event and waits on it.

    When some other client posts data to the server, it notifies all applications on
    the "New Message in Chat Room no 134" event and they wake up and send these messages
    to clients, and so on.

    This model is still looks like quite "low level" model, but it hides all
    notification methods.

  2. Another option is to define some named queues, so each client creates such
    queue upon connection to server and waits for new messages. When some client
    posts a new message to "Chat Room no 134", on the server side it is broadcasted
    to all queues connected to this "Chat Room no 134", and the message is delivered
    to client.

    However there are many questions that are risen:

    • How do I manage queues and the session level, at the level of single page?
    • How do I delete queues and create timeouts on them?
    • What happens if more then one "window" subscribes to same queue?
  3. Create a persistent object on server side that glues between server side events
    and user side events. It may communicate over distinct XHR requests that are
    redirected to it.

    So client (JavaScript) registers events and waits for them with XHR
    and server side dispatched event notifications, until the page is rebuild.

So, I would like to know, what are most popular and recommended
API models behind server side push technologies?

Thanks

Edit: Added third option

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

笑叹一世浮沉 2024-08-06 02:48:32

尝试 Bayeux,它非常像您的第一个模型。 客户端订阅频道“chatroom/new-message/134”。 如果有新的消息,服务器将广播给订阅者

您可以使用通配符频道名称订阅多个房间“chatroom/new-message/*”(仅尾随)

Try Bayeux, it's very much like your first model. The client subscribe to channel "chatroom/new-message/134". If there are new message, the server will broadcast to the subscribers.

You can use wildcard channel name to subscribe to multiple rooms "chatroom/new-message/*" (trailing only)

北座城市 2024-08-06 02:48:32

没有适合所有应用的通用解决方案。 如果您想了解一些通用模式,请查看事件驱动架构

有一些幻灯片来自我参加的一个演示文稿一次(这是对该主题的一个相当高层次的看法)。

There's no general solution that fits all applications. If you want to learn about some general patterns, have a look at Event-Driven Architectures.

There are some slides online from a presentation I attended once (it's a quite high-level view of the topic).

转瞬即逝 2024-08-06 02:48:31

您应该查看 XMPP PubSub,它定义了基于 XMPP 的通用发布/订阅协议。 还有一个名为 BOSH 的 XMPP 扩展(较低级别的协议详细信息单独记录在 < a href="http://xmpp.org/extensions/xep-0124.html" rel="nofollow noreferrer">XEP-0124) 定义了一种机制,允许 HTTP 客户端使用 long 绑定到 XMPP 服务器-轮询(即彗星)。 结合这两个规范,您可以为使用 Comet 的 Web 应用程序提供强大的事件订阅模型。 即使您最终没有使用 XMPP/BOSH,规范也包含一些关于如何构建此类系统的有价值的见解。

如果您最终使用 XMPP 和 BOSH,这里有一些您可能会发现有用的工具:

  • StropeJS:A用于编写使用 BOSH 的客户端 XMPP 客户端的库。
  • Idavoll:XMPP 服务器的通用发布-订阅服务组件。
  • Punjab:一个 BOSH 连接管理器,充当 BOSH HTTP 客户端和您的服务器之间的一种“转换代理” XMPP 服务器。

诚然,这是一个非常重量级的解决方案,它可能不适合您的特定应用程序,但这些标准经过了很多思考,因此它们可能会有所帮助。

You should check out XMPP PubSub, which defines a generic publish/subscribe protocol over XMPP. There's also an XMPP extension called BOSH (lower-level protocol details are documented separately in XEP-0124) that defines a mechanism that allows HTTP clients to bind to XMPP servers using long-polling (i.e., comet). Combining these two specifications gives you a robust event subscription model for web-apps using comet. Even if you don't end up using XMPP/BOSH, the specs contain some valuable insight into how this sort of system can be built.

If you do end up using XMPP and BOSH here are some tools you may find useful:

  • StropheJS: A library for writing client-side XMPP clients that speak BOSH.
  • Idavoll: A generic publish-subscribe service component for XMPP servers.
  • Punjab: A BOSH connection manager that acts as a sort of "translating proxy" between BOSH HTTP clients and your XMPP server.

Admittedly this is a very heavy-weight solution, and it may not be appropriate for your particular application, but a lot of thought was put into these standards so they may be helpful.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文