在线游戏中玩长轮询框架
我正在使用 play 框架开发一个浏览器游戏，我肯定需要长轮询，但我不太明白如何使用它。 WebSockets 非常适合这种情况，但目前还没有很多浏览器支持它。
这就是我想要做的：当用户登录并导航到玩游戏控制器时，我想启动连接并保持打开状态。我想为所有在线用户执行此操作，这样我就可以在网站上显示他们的列表，以便他们可以互相玩。我查看了文档，但我不明白如何在我的案例中实施它。因为我根本没有想要计算的任何内容（在他们生成 pdf 的示例中），我只是希望连接保持打开状态。
我还想知道，我应该如何跟踪所有这些开放的连接？现在，我在数据库的用户表中只有一个 online 列，我会更新该列。所以每次有人连接时我都必须更新数据库。有没有更好的方法可以做到这一点，或者这样可以吗？
最后，假设上述所有内容都有效。当玩家 A 选择玩家 B 一起玩时：我如何通知玩家 B？我是否只发送一些 JSON 代码，并在玩家 B 一侧使用 javascript 更改页面，或者将他发送到完全不同的页面？我不确定当两个连接建立并且游戏开始时如何进行通信。
I'm working on a browser game with the play framework, and I definitely need longpolling, but I don't quite understand how to use it. WebSockets would be perfect for this, but it's not supported by that many browsers yet.
Here's what I want to do: When the user logs in, and navigates to the play game controller, I want to start a connection, and keep it open. I want to do this for all users that are online, so I can show a list of them on the site, so they can play with each other. I've looked at the documentation, but I don't understand how I could implement it in my case. Because there simply isn't anything I want to calculate (in the example they're generating a pdf) I just want the connection to stay open.
What I'm also wondering is, how I should keep track of all these open connections? Right now, I just have an online column in my users table in the database, which I update. SO everytime someone connects I have to update the database. Are there better ways to do this, or is this fine?
And lastly, assuming all of the above works. When player A, selects player B to play with: how do I notify player B of this? Do I just send some JSON code, and change the page with javascript, on player B's side, or do I send him to a totally different page? I'm not sure how to communicate when the two connections are established and the game has started.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
首先，我认为您需要了解 Websockets 和长轮询之间的区别。
Websockets 创建一个连接并保持其打开状态，直到浏览器通过某些 JavaScript 终止会话或用户离开页面。这将为您提供您所请求的所需性质。查看 Play 下载中的聊天示例将向您展示如何使用 Websockets 处理整个聊天应用程序。
进一步阐述 Pere 关于 Play 无国籍状态的回答。 Play 创建者建议，单个 Websocket 连接，无论打开多长时间以及来回发送多少请求，都被视为单个事务。因此，不需要在每个 Websocket 请求之间保存到数据库（同样，您可以看到聊天示例中没有保存任何内容）。使用此方法，您需要在 Websocket 最终关闭时保存详细信息，或者实际上是所有 Websocket，具体取决于您的用例。
另一方面，长轮询打开与服务器的连接，服务器只需等待，直到有数据发送回客户端。如果您需要将任何数据推送到服务器，您可以将其作为单独的 AJAX 请求来执行，因此您实际上可以同时打开两个请求。您不一定知道用户何时注销，除非您在用户离开页面时发送请求，让服务器知道他们已经离开，但这并不总是成功。长轮询可以工作，但它不像 Websockets 那样简洁，但正如您所说，这尚未得到广泛支持。
我的建议是研究聊天示例（因为它有长轮询和 Websockets 版本）。这将是启动并运行您的要求的最有效方法。
至于您关于如何通知其他玩家的最终疑问。在长轮询中，您只需使用一些 JSON 响应挂起的请求即可。使用 websockets，您可以将事件发送回客户端。同样，这两种方法都可以从聊天示例中清楚地看出。
我还在 Websockets 上写了一篇博客文章，这可能帮助您更好地理解这个过程。
Firstly, I think you need to appreciate the difference between Websockets and Long Polling.
Websockets creates a connection and keeps it open until the browser terminates the session, via some javascript or the user moving on from the page. This would give you the desired nature of what you are requesting. Looking at the Chat example in the Play download will show you how an entire Chat application is handled using Websockets.
Further to Pere's answer regarding Play's statelessness. The Play creators have suggested that a single Websocket connection, regardless of how long it is open for and how many requests are sent back and forther, is considered to be a single transaction. Therefore, saving to the database in between each Websocket request is not needed (again, you can see that nothing is saved in the Chat example). Using this method, you would be expected to save the details when the Websocket is finally closed, or indeed all Websockets, depending on your use-case.
Long Polling on the other hand opens a connection to the server, and the server simply waits until there is something to send back to the client. If you need to push any data to the server, you would do this as a separate AJAX request, so you would effectively have two requests open at once. You don't necessarily know when a user logs off, unless you send a request just as they leave the page, to let the server know they have gone, but this is not always successful. Long Polling can work, but it is not as neat a solution as Websockets, but as you say, this is not widely supported yet.
My suggestion would be to study the Chat example (as it has a Long Polling and Websockets version). This will be the most effective way to get up and running with your requirements.
As for your final query regarding how to notify the other player. In Long Polling, you would simply respond to the suspended request with some JSON. With websockets, you would send an event back to the client. Again, both approaches can be pretty clearly figured out from the Chat example.
I have also written a Blog post on Websockets, which may help you understand this process a little better.
在 Websocket 部分，您可以在此处看到（第一个答案）支持还不错，如果浏览器出现问题，您可以使用 Javascript 进行回退。这将简化您的场景，因为长轮询可能更难以管理。
关于跟踪问题，由于 Play 是无状态的，您必须将标志存储在数据库中，并在关闭连接时将其删除。否则你就打破了无国籍状态。
关于通知，您必须向 B 发送一些消息，但不要将它们移动到其他页面，因为这可能会造成混乱并导致不良的用户体验。使用 Json 弹出一些消息（在 div 中），提醒他们游戏开始或请求玩。
On the Websocket part, as you can see here (1st answer) the support is not so bad, and you have a Javascript fallback if there is some problem with the browser. This would simplify your scenario, as long polling may be more complicated to manage.
On the issue of keeping track, as Play is stateless you have to store the flag in the database and remove it when they close the connection. Otherwise you are breaking the statelessness.
About the notification, you have to send some message to B, but don't move them to another page as it may be confusing and cause bad user experience. Use Json to pop some message (in a div) alerting them of the game starting or the request to play.
我没有使用“play”框架。
但我最近一直在研究和修补基于 http 的长轮询。 Websocket（如果可用）更适合实时消息！
至于长轮询，我发现使用“货运卡车”类比可以帮助我非常有效地推理长轮询。这是我就该主题写的一个小注释：
http://dvb。 omino.com/blog/2011/http-comet-realtime-messages/
也许您或未来的 greppers 可能会发现它很有用。
I'm not using the "play" framework.
But I've been lately researching and tinkering with http-based long polling. Websockets, if available, is much more appropriate for realtime messages!
As for long-polling, I found that using a "cargo truck" analogy helped me reason about long-polling quite effectively. Here's a little note I wrote on the subject:
http://dvb.omino.com/blog/2011/http-comet-realtime-messages/
Perhaps you or future greppers may find it useful.
您可能还想看看基于 Node 的 Juggernaut 项目。 Node.js 和 Redis 并为您提供“服务器和客户端浏览器之间的实时连接”。当使用像 Jedis 这样的 Java Redis 客户端时，您应该能够轻松集成整个Play 框架的事情！
You might also want to take a look at the Juggernaut project which is based on node.js and Redis and gives you a "realtime connection between your servers and your client browsers". When using a Java Redis client like Jedis, you should easily be able to integrate the whole thing with the Play framework!