假设我有两个应用程序必须在一定程度上协同工作。
- 一个 Web 应用程序（PHP、Ruby on Rails，...）
- 桌面应用程序（Java、C++、...）
必须从 Web 应用程序通知桌面应用程序，并且发送和接收通知之间的延迟必须很短。（< 10 秒）
有什么可能的方法来做到这一点？我可以考虑以 10 秒的间隔进行轮询，但如果必须通知许多桌面应用程序，那将产生大量流量。在 LAN 上，我会使用 UDP 广播，但不幸的是，这在这里是不可能的......
我很感激你能给我的任何想法。
问问题
352 次
4 回答
3
我可以看到两种方式：
- 您的桌面应用程序轮询 Web 应用程序
- 您的 Web 应用程序通知桌面应用程序
您的 Web 应用程序可以发布 RSS 提要，但您的桌面应用程序仍需要每 10 秒轮询一次提要。
流量不需要很大：如果你使用 HTTP HEAD请求，你会得到一个带有最后修改日期的小数据包（方便地命名为Last-Modified）。
于 2009-05-03T15:02:01.317 回答
3
我认为这里的“最佳实践”将取决于您希望服务的桌面客户端的数量。如果只有一个桌面需要通知，那么轮询可能是一种很好的方法——是的，轮询比基于事件的通知开销更大，但它肯定是最容易实现的解决方案。
如果轮询的开销确实不可接受，那么我看到了两个基本的选择：
- 保持桌面和网络服务器之间的持久连接打开（可能是“彗星”风格的网络请求，或原始套接字连接）
- 从桌面应用程序中公开服务，并将服务的地址注册到 Web 服务器。这样，网络服务器可以根据需要调用桌面。
不过请注意——这两种选择都充满了陷阱。几个亮点：
- 保持连接打开可能很棘手，因为您希望您的网络服务器可热插拔
- 从 Web 服务器调用外部服务（例如，您的桌面）是危险的，因为此请求可能会挂起。您希望将此通知移到单独的线程上，以避免占用网络服务器。
为了减轻一些担忧，您可以通过引入中间通知服务器来将不可靠的桌面与网络服务器分离——网络服务器可以在某处发布更新，桌面可以在那里轮询/连接/注册以得到通知。为了避免在这里重新发明轮子，这可能涉及某种 MessageQueue 系统……当然，这增加了需要维护新中介的复杂性。
同样，所有这些方法可能都相当复杂，所以我想说轮询可能是最好的选择。
于 2009-05-03T20:19:14.267 回答
1
我不确切知道如何完成您的任务，但我可以建议在桌面应用程序 PC 上创建一个 Windows 服务。
此服务每隔一段时间检查 Web 应用程序是否有新更改，如果发生更改，它可以运行桌面应用程序并通知 Web 应用程序发生更改，并且当 Web 应用程序发生任何更改时，您可以通过确认进行响应
我希望这可能有用我没有完全尝试过，但我建议使用这样的想法。
于 2009-05-03T14:43:28.787 回答
1
一层联合将有助于扩展系统。
桌面应用程序可以向“发布者”服务注册自己（在多台/多台机器中的一台上运行）此发布者服务从您的 Web 应用程序接收“通知”，表明某些内容发生了变化，并立即开始通知其所有注册订阅者。
您需要的发布者数量会随着用户数量的增加而增加。
编辑：忘了提到桌面应用程序需要在套接字上侦听。
于 2009-05-31T08:57:07.417 回答