iPhone 大型多人在线角色扮演游戏中的高延迟
现在我正在尝试为 iPhone 制作一款大型多人在线角色扮演游戏。我将其设置为 iPhone 每秒多次请求玩家位置。它是如何做到这一点的：客户端使用异步 NSURLConnection 向 php 页面发送请求，该页面从 mysql 数据库加载位置并以 json 形式返回。然而，从请求位置到实际加载大约需要 0.5 秒。这看起来确实很高，有什么明显的事情可能导致这种情况吗？
此外，这也会导致客户端上的玩家移动非常不稳定。是否有任何算法或方法可以减少玩家移动的不稳定性？
Right now I'm trying to make a mmorpg for the iPhone. I have it set up so that the iPhone requests for the player positions several times a second. How it does this is that the client sends a request using asynchronous NSURLConnection to a php page that loads the positions from a mysql database and returns it in json. However, it takes about .5 seconds from when the positions are requested to when they actually get loaded. This seems really high, are there any obvious things that could cause this?
Also, this causes the player movement on the client to be really choppy too. Are there any algorithms or ways to reduce the choppiness of the player movement?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
开始测量在 iPhone 外部运行数据库查询所需的时间。
然后测量当您从 iPhone 以外的其他设备发送相同的 http 请求时需要多长时间（例如，使用 10-15 行 c# 程序来解决这个问题）。
如果以上均未显示出任何明显的延迟，则需要在 iPhone 端进行改进。需要注意的一些事项：
GPRS/3G 的延迟相当高
GPRS/3G 具有相当高的误码率 - 这意味着时不时会有相当多的丢包，这将导致 tcp 重新传输，您将体验到更高的延迟
HTTP 有很多开销。
JSON 增加了大量开销。
也许您需要为消息提供一种紧凑的二进制格式，并放弃 HTTP，转而采用自定义协议 - 甚至可能恢复为 UDP
上述几点通常不适用，但如果您需要提供一个高延迟、低带宽、不稳定连接的流畅体验。
我没有关于玩家移动算法的任何具体信息，但经常使用的是某种移动预测。
您知道玩家移动的方向，如果速度不总是恒定，您可以得出速度 - 这意味着您可以随着时间的推移进行插值并猜测他的新位置，在查询实际位置时调整屏幕上的位置，然后进行调整当您收到查询响应时返回到实际位置。
诀窍是始终在一定的边界内随时间进行插值。如果您的预测与查询返回的结果相比有点偏差，请不要立即将位置恢复到真实位置。在几帧上在当前位置和所需位置之间进行插值。
Start measuring how long the database query takes when you run it outside your iPhone.
Then measure how long it takes when you send the same http request from something other than your iPhone(It's e.g. a 10-15 line c# program to figure this out).
If none of the above show any sort of significant latency, the improvements need to be done on the iPhone side. Some things to look out for:
GPRS/3G has rather high latency
GPRS/3G has rather high bit error rates - meaning there's going to be quite a few dropped packets now and then which will cause tcp to retransmit and you'll experience even higher latency
HTTP has a lot of overhead.
JSON adds a lot of overhead.
Maybe you'll need to come up with a compact binary format for your messages, and drop HTTP in favor of a custom protocol - maybe even revert to UDP
The above points generally don't apply, but they do if you need to provide a smooth experience over high latency,low bandwidt, flaky connections.
I don't have any specific info on player movement algorithms, but what is often used is some sort of movement prediction.
You know the direction the player is moving, you can derive the speed if it's not always constant - this means you can interpolate over time and guess his new position, adjust the on screen position while you're querying for the actual position, and adjust back to the actual position when you get the query response.
The trick is to always interpolate over time within certain boundaries. If your prediction was a bit off compared to what the query returned, don't immediatly snap the positon back to the real position. Do interpolation between the current position and the desired postion over a handful of frames.
在服务器端，您应该使用一些保持运行并保持数据库连接始终打开的系统。最好它也会缓存东西，而不是一直从数据库请求它们。
另外，不要为每次更新发出新的 HTTP 请求。如果您根本不需要使用 HTTP 那就最好了，因为它确实不适合实时通信。
GPRS 通常具有 600 毫秒 ping 时间，3G 具有 300 毫秒，HSPA 具有 100 毫秒。查看正在使用哪种模式。请注意，当没有足够的流量来证明更快的模式是合理的时，某些设备（我不知道 iPhone）会出于省电的原因从 HSPA 下降到常规 3G。
对于位置，一种相当常见的做法是应用线性预测，即让角色以当前速度继续沿当前方向移动，即使服务器还没有可用的数据。
最重要的是：基准/配置文件以查看延迟在哪里。是你的服务器、网络连接还是应用程序。
On the server side you should be using some system that keep running and that keeps the database connection open all the time. Preferably it would also cache things instead of requesting them from database all the time.
Also, do not make a new HTTP request for every update. It would be best if you hadn't need to use HTTP at all, as it really isn't suitable for realtime comminunication.
GPRS typically has 600 ms ping time, 3G has 300 ms and HSPA has 100 ms. See which mode is being used. Notice that some devices (I don't know of iPhone) drop from HSPA to regular 3G for power-saving reasons whenever there is not enough traffic to justify the faster mode.
As for position, a rather common practice is to apply a linear prediction, i.e. make the character continue movement in current direction, at the current speed, even when no data from server is available yet.
Most importantly: benchmark/profile to see where the latencies are. Is it your server, the network connection or the application.
快速加载玩家位置也有缺点。
所以我认为目前大型多人在线角色扮演游戏如果没有一些必要的捷径就可以工作，例如根据速度和位置推断路径。加载职位的速度不会如您所愿，尤其是在基于 PHP 的服务器上。
无论哪种方式，在为移动平台进行开发时，与功能齐全的桌面实现相比，您都必须在功能方面做出牺牲。
如果不是用更快的语言（例如 C++）重新实现整个服务器，我也可能会重新实现一些更关键的东西。
Loading the player positions that fast has downsides.
So I don't see a mmorpg working without some necessary shortcuts at this time, e.g. extrapolating paths based on their velocity and position. Loading positions will not work as fast as you want, especially with a server based on PHP of all things.
Either way, when developing for a mobile platform you're going to have to make sacrifices in terms of features versus a fully-featured desktop implementation.
I might also reimplement some of the more critical stuff if not the whole server in a faster language, e.g. C++.