我正在考虑创建一个实时应用,其中iPod Touch / iPhone / iPad与服务器端组件(生成MIDI,并在主机内向前发送)进行通信。当我在Wifi上ping我的iPod Touch时,我会遇到很大的延迟(并且也有很大的差异):
64 bytes from 192.168.1.3: icmp_seq=9 ttl=64 time=38.616 ms
64 bytes from 192.168.1.3: icmp_seq=10 ttl=64 time=61.795 ms
64 bytes from 192.168.1.3: icmp_seq=11 ttl=64 time=85.162 ms
64 bytes from 192.168.1.3: icmp_seq=12 ttl=64 time=109.956 ms
64 bytes from 192.168.1.3: icmp_seq=13 ttl=64 time=31.452 ms
64 bytes from 192.168.1.3: icmp_seq=14 ttl=64 time=55.187 ms
64 bytes from 192.168.1.3: icmp_seq=15 ttl=64 time=78.531 ms
64 bytes from 192.168.1.3: icmp_seq=16 ttl=64 time=102.342 ms
64 bytes from 192.168.1.3: icmp_seq=17 ttl=64 time=25.249 ms
即使这是iPhone->主机或主机 - > iPhone时间的两倍,对我正在考虑的应用来说,15ms +太长了。 有没有更快的方法(例如,USB线)?如果没有,在Android上构建应用程序会提供任何其他选项吗?
Traceroute报告更多可行时间:
traceroute to 192.168.1.3 (192.168.1.3), 64 hops max, 52 byte packets
1 192.168.1.3 (192.168.1.3) 4.662 ms 3.182 ms 3.034 ms
任何人都可以为我解读ping和traceroute之间的这种区别,以及它们对于需要与主机(以及来自)主机通信的应用程序可能意味着什么?
答案 0 :(得分:4)
请记住,ping的“往返”包括host1-> AP-> host2-> AP-> host1的时间,而traceroute的“往返”包括host1-> AP->主机1。那些ping RTT时间实际上非常好。在我家,他们平均接近250毫秒,并且我的3GS经常达到300毫秒。
Ping响应时间受内核可用性的影响。如果在ICMP请求进入时CPU处于忙碌状态,则会对其进行缓冲,直到CPU可以处理它为止。在资源受限的设备(如iPhone(或者说,负担过重的路由器))上存在大量机会阻止这种阻塞。此外,iPhone OS将在某种程度上尝试对数据包进行排队以便以突发方式进行传输。这可以防止无线电连续发射,从而节省电力。当然,这会影响延迟,并会挑战任何需要低延迟和/或稳定延迟的应用(例如VoIP)。
目前没有基于USB的TCP / IP公共标准(而不是1394,有)。由于USB是串行链路层,理论上可以使用您自己的协议或预定义的协议(例如PPP)通过坞连接器传递数据。一旦建立了EASession,就会在正常的NSInputStream / NSOutputStream上进行通信。
答案 1 :(得分:4)
我认为这可能是WiFi省电模式会让你失望。我认为手机可以缓冲数据包并仅偶尔发送出去。我在N900上看到了与WiFi类似的行为。
请注意您发布的ping中的强烈模式。这可能是由ping和天线周期性地开启和关闭产生的节拍模式。
答案 2 :(得分:1)
我与Verizon和AT& T进行了大量的细胞工作。 指向移动设备时的Ping时间必须在理解任何初始连接尝试将高于正常情况的情况下进行。
如果我们针对ping RTT看到的基线对于AT& T平均约为300毫秒。 Verizon 400 ms到600 ms甚至更高。
但每个运营商的第一个数据包必须首先找到移动设备。因此,你得到的第一个反应可能真的(真的)很高。 3000毫秒到高达4500毫秒是我在我管理的网络上看到的,它有2700个移动终端,我们定期从监控系统连接。
此外,任何具有大量RF噪声的环境都会产生延迟并丢弃数据包。即使你的家也会产生大量的噪音干扰无线电设备。
这可能没什么用,但是......如果你可以使用具有更好缓冲功能的API,你可能会更好......或者更密切地关注你正在考虑使用的当前API的缓冲功能
我希望你能让它运转起来=)