实时浏览器游戏服务器
我主要是在寻找设置建议和有关如何进行此操作的指导。我将尽可能详细地解释，并指出可能可行的方法。
这样做的目的是创建一个实时浏览器游戏，我发现满足我的需求的最佳方法是使用ajax的“长轮询”，这基本上会向服务器设置一个请求，该请求将“挂在那里”直到服务器有东西要发送，然后在收到更多数据后重新建立连接。出于我的目的，这将处理聊天系统以及角色移动，IE：如果玩家进入同一区域，那里的客户端将收到通知他们的响应，从而更新浏览器客户端以显示这一点。
上面的实现相对容易，我已经为它做了一个测试用例，但是我想改进它，在服务器端它运行一个循环 X 时间，然后它会自动超时并发送回来空字符串，因此可以建立另一个连接，这是为了防止无限循环并在不应该的情况下耗尽资源。我使用平面文件，而不是在每个循环周期查找数据库（我相信这会很昂贵）来获取需要发送到客户端的消息，如果文件的修改时间戳大于发送到客户端的最后一条消息，那么有有新的东西要发送。然而，我相信当每秒执行几次时，这也会很昂贵（不过不如使用 mysql 数据库那么贵？）。
我对此的思考过程是让一个 C++ 程序（为了速度）不断运行，并使用它在内存中非常快速地查找新消息，第四，这也会给我带来额外的好处，即能够在服务器可以控制游戏以获得更实时的感觉/方法，但是我不知道这是否可能，而且我在谷歌上的搜索毫无结果。
我最希望能够做到的方法是继续使用 PHP 来进行页面的渲染和控制等，并将 ajax 请求发送到可以处理所有内容的 C++ 应用程序（将始终运行）实时方面。
CGI 违背了上述方法的目的，因为它在每个请求上创建一个新的应用程序实例，这既慢又正是我不想要的，我有 php 来实现这一点，并且不想切换一种完美运行的语言对于另一个更适合的，PHP 然而（据我所知）不能将东西存储在内存（ram）中，所以第四。
我考虑过的另一种方法是使用 php 套接字连接到 C++ 应用程序，尽管我不知道这有多可行。 C++ 应用程序基本上只需要控制机器人（AI）和聊天系统消息。我完全不知道如何通过 PHP 处理机器人。
我希望这充分解释了我的意图和目标，所以如果有人有任何指示或建议，请回复并帮助我，我们将非常感激。如果您需要任何额外的信息（因为如果我没有很好地介绍某些内容或某些内容），那么我将很乐意尝试更好地解释。
I'm mostly looking for setup advise and pointers on how to go about going about this. I'll explain in as much detail as I can think and also note possible approaches that may be plausible.
The aim of this is to create a real time browser game, the best method that I have found for my needs would to use "long polling" with ajax, which will basically setup a request with the server that will "hang there" til the server has something to send it, then re-establish the connection upon receipt for more data. For my purposes this will handle a chat system aswell as character movement, IE: if a player enters the same area the clients there will recieve a response to inform them and thus update the browser client to show this.
The above is relatively easy to implement and I have already made a test-case for it, however I want to improve on it, on the server side it runs a loop for X amount of time before it'll auto timeout and send back and empty string, so another connection can be made, this is to prevent infinite loops and use up resources in cases where it shouldn't. Instead of looking up the database on each loop cycle (would be expensive I believe) for messages that need sending to the client, I use flatfiles, if a file has a modified timestamp greater than the last message sent to the client, then there is something new to send. However I believe this would also be expensive (not as much as using a mysql database though?) when done a couple of times per second.
My thought process on this was to have a C++ program (for speed) constantly running, and use that for very fast lookups in memory for new messages and so fourth, this would also give me the added bonus of being able to have bots within the game that the server can control for a more real-time feel/approach, however I have no clue if this is even possible and my searches on google have been fruitless.
The approach I would most love to be able to do, is to continue to use PHP to do the rendering and control of the page etc, and have the ajax requests go to the C++ application (that will always be running) that can handle all the real-time aspects.
CGI defeats the purpose of the above approach, as it creates a new instance of the application on each request, which is both slow and exactly what I do not want, I have php for that and don't want to switch one perfectally running language for another that would be better suited, PHP however (to my knowledge) can't store things in memory (ram) and so fourth.
Another approach that I have thought about was to use php sockets to connect into the C++ application, though I have no idea how feasible this may be. The C++ application only basically will need to control bots (AI) and the chat system messages.. I have absolutely no idea how to go about handling bots via PHP.
I hope this fully explains what my intentions and goals are, so if anyone has any pointers or advise then please reply and help me out, it would be very much appreciated. If you need any extra information (for if I didn't cover something or something very well) then I'll be happy to attempt to better explain.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
反应需要多快？对于任何接近实时动作的游戏，AJAX/Comet 都会太慢。开销也确实令人沮丧。
此类事情的前进方向可能是 WebSocket，在后端。但我不认为这意味着您需要为此求助于 C[++]；瓶颈很可能是网络，而不是服务器处理器能力。
我使用的是带有简单消息复制系统的 Python SocketServer - 在我的例子中，所有游戏逻辑都在客户端，一些复杂的 JavaScript 在面对延迟时维持一致的游戏世界 - 但即使对于更复杂的服务器-side 我认为脚本语言可能就很好了。
WebSocket 还没有准备好；没有主流浏览器实现。与此同时，我正在使用模拟 WebSocket 接口的 Flash Socket 备份。 Flash Sockets 有自己的问题，因为它们无法协商代理，但它们速度很快，并且希望随着 WebSocket 的正确到来，对它们的需求会减少。
How fast do the reactions need to be? For anything approaching real-time action games, AJAX/Comet is going to be much too slow. The overhead is also really depressing.
The way forward for that kind of thing will probably be WebSocket, with a custom server on the backend. But I don't think that means you need to resort to C[++] for this; the bottleneck is most likely going to be the network and not server processor power.
I'm using a Python SocketServer with a trivial message replication system — all the game logic in my case is on the client-side, with some complicated JavaScript maintaining a consistent game world in the face of lag — but even for a more complex server-side I think a scripting language will probably be just fine.
WebSocket isn't ready yet; there are no mainstream browser implementations. In the meantime I'm using a Flash Socket backup that emulates the WebSocket interface. Flash Sockets have their own problems in that they fail to negotiate proxies, but they are fast and hopefully the need for them will diminish as WebSocket arrives properly.
读你的帖子会敲响警钟。
您对多线程代码有多熟悉？用C++？如果答案是“不太”，那么我担心你可能会咬掉一大块。为什么不利用一些现有的（经过尝试和测试的）COMET 服务器实现而不是这种准系统方法呢？无论您想要什么应用程序，它都应该与通信实现完全分开。
作为已经实现了此类服务器的人，我可以告诉您，这将需要多次设计迭代和非常长的时间才能完成。实际测试这样的产品也是一个非常棘手的过程。
Reading your post sets alarm bells ringing.
How familiar are you with multi-threaded code? With C++? If the answer is "not very", then I fear you might be biting off a quite a large chunk. Why not take advantage of some existing (tried and tested) COMET server implementations rather than this barebones approach? Whatever application you have in mind, it should be quite separate from the comms implementation.
As someone who has implemented a such a server, I can tell you that it will take many design iterations and a helluva long time to get right. Testing such a product realisticly is also a very tricky process.