使用 GWTP 实施服务器推送
我有一个使用 GWTP 的项目（涉及 MVP 分离、Gin 和 Dispatch），现在我面临的情况是需要将服务器上的更改推送到特定客户端
我已经阅读了 gwt-comet 和 gwteventservice 文档，似乎第一个不适用于 RPC，第二个 Ecnapsulates RPC，我不知道如何将其适合我当前的 GWTP 命令模式。有想法吗？
I got a project using GWTP (which involves MVP separation, Gin and Dispatch), now I'm on the situation where it is required that changes on the server are pushed to specific clients
I've reading the gwt-comet and gwteventservice documentation, It seems the first doesn't work with RPC and the second Ecnapsulates RPC, for which I don't know how to fit it in my current command pattern from GWTP. Ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我一直在使用 gwt-comet (http://code.google.com/p/gwt-彗星/）。它是一个本地 Comet 实现，工作得非常像 RPC，您也可以发送字符串或 GWT 序列化对象。最好的事情是你不需要做很多事情就能让它发挥作用。
I have been using gwt-comet (http://code.google.com/p/gwt-comet/). It's a native comet implementation working pretty good like RPC, you can send Strings or your GWT-serialized objects as well. And the best thing you don't need to do many things to make it works.
我使用了此处描述的“GWT 中的服务器推送”http://code .google.com/p/google-web-toolkit-incubator/wiki/ServerPushFAQ - 对于一个小项目来说，它似乎工作得相当好。
i used "Server Push in GWT" described here http://code.google.com/p/google-web-toolkit-incubator/wiki/ServerPushFAQ - it seemed to work fairly well for a small project.
这实际上是一个 servlet 问题，而不是 GWT 或 GWTP 问题。
因此，有几种方法可以做到这一点，最稳定的（在我看来）是使用长的或阻塞的 poll servlet。这基本上是一个由客户端轮询的 servlet，如果没有消息“推送”到客户端，并且时间过长（这是为了解决 http 超时问题），它会在一段时间内保持连接打开以某种方式返回心跳。无论哪种方式，当servlet请求request返回时，客户端只是发出另一个请求。在我看来，这是最便携、最稳定的方式，因为它仅使用核心 servlet api，不会遇到网络问题，并且阻塞部分允许您将轮询“停放在”服务器一段时间并减少总请求负载，同时允许在有可用信息时非常快速地将新信息返回给客户端。
实现这一目标的下一个方法是通过 WebSockets，一旦你让它工作起来就很棒，在我看来，毫无疑问这是未来的方式。我认为这是一个很好的合作方式，因为在我看来，一旦它流行起来，这将是 Web 应用程序的范式转变，所以我们都需要跟上速度。基本上，您有一个通过端口 80 打开的 javascript“套接字”（这是最好的功能之一，因为您不必打开任何防火墙漏洞），并且可以通过该套接字在两个方向上进行通信。
Comet 也可以工作，但它通常会将您锁定到一种服务器类型，这可能适合您的应用程序。这里警告一下！！！！我只用 Comet 做了非常小的测试，当我设置它时，它对我来说很不稳定，并且不如阻塞轮询解决方案稳定因为我设置它。
现在，我认为最巧妙的一种方法是使用基于小程序的推送，但由于可能对单域 Intranet 应用程序的网络限制，这种方法非常有限。此设置（可以使用 udp 或直接套接字完成，我使用所有 Web 只是为了在概念上保持简单）采用小程序，使用它在客户端上启动 jetty 服务器实例，然后让页面发布客户端到服务器的码头“端点”。此时，客户端可以使用其 servlet 联系服务器，服务器也可以通过 jetty 服务器上公开的 servlet 联系客户端。这是真正的推送，很整洁，但是存在网络噩梦。
因此，在上述所有内容中，我使用长轮询，关注网络套接字，因为它们是我心目中的未来，并且非常喜欢基于小程序的版本，尽管由于网络分辨率限制，它的使用受到很大限制。
一旦您做出决定，从 GWTP 您只需根据需要使用操作或 JSNI 桥接方法来连接到您的服务器并接收响应。我不会讨论这个，因为这实际上是一个核心 servlet/http/javascript 问题，而不是一个以 GWT 或 GWTP 为中心的问题。
我希望这有帮助！
This is really a servlet problem, not a GWT or GWTP problem.
So there are a few approaches to doing this, the most stable (in my opinion) is to have a long or blocking poll servlet. This is basically a servlet that is polled by the client, and holds the connection open for some period of time if there is no message to 'push' to the client, and if too much time passes (this is to get around http timeouts) a heartbeat is returned of some kind. Either way, when the servlet request request returns, the client just makes another request. This is the most portable and stable way to my mind, since it uses only the core servlet api, doesn't suffer from network issues, and the blocking portion allows you to have the poll 'park' at the server for some period of time and reduces total request load, while allowing very quick return of new information to the client when there is some available.
The next way to achieve this is via WebSockets, this is great once you get it working and in my opinion is the way of the future without question. I think this is a good one to work with since this will be, in my opinion, a paradigm shift in web applications once it catches a head of steam, so we all need to be up to speed. Basically, you have a javascript 'socket' open via port 80 (this is one of the best features, since you don't have to open any firewall holes) and can communicate in two directions across that socket.
Comet can also work, but it will generally lock you down to one server type, which may be alright for your application. Caveat here!!!! I have only done very small tests with comet, it was flaky for me when I set it up, and was not as steady as the blocking poll solution as I had it set up.
Now the neatest one in my opinion, but this one is very limited due to network constraints probably to single domain intranet applications, is to use an applet based push. This setup (which could be done with udp or a straight socket, I did all web just to keep it all simpler conceptually) takes the applet, uses it to spin up a jetty server instance on the client, and the has the page publish the client's jetty 'endpoint' to the server. At this point, the client can contact the server using it's servlets, and the server can contact the client at the servlet(s) exposed on the jetty server. This is true push, it's neato, but there are network nightmares.
So of all the above, I use long polling, keep my eye on web sockets since they are the future in my mind, and really like the applet based version, although it's quite restricted in use due to the network resolution limitations.
Once you have this decided, from GWTP you would just have actions or JSNI bridge methods as needed to connect to your server and receive responses. I won't go into this, since this is really a core servlet/http/javascript question more than a GWT or GWTP centric question.
I hope that helps!