스로틀을 피하는 방법?

네트워크로 연결된 iOS 게임을 작성하고 있습니다. 초당 60 개의 패킷 (인접한 패킷 사이의 16ms)으로 패킷을 보낼 때 GKMatchSendDataReliable( 자신의 패킷 수신 코드가 UDP 인 것으로 가정 ) 평균 핑 시간이 급격히 악화됩니다. ), 단순히 100 패킷의 "홍수"(초당 60 패킷의 속도로)를 보냈습니다. 평균 왕복 시간을 측정 한 결과는 다음과 같습니다.

[ 21:16:39 ]:  I saw an average roundtrip time of 52.342787 ms, he saw 54.496590 ms
[ 21:16:34 ]:  I saw an average roundtrip time of 62.631942 ms, he saw 61.991655 ms
[ 21:16:45 ]:  I saw an average roundtrip time of 88.394380 ms, he saw 83.619123 ms
[ 21:16:51 ]:  I saw an average roundtrip time of 179.053118 ms, he saw 156.869141 ms
[ 21:16:57 ]:  I saw an average roundtrip time of 75.025076 ms, he saw 75.419723 ms
[ 21:17:23 ]:  I saw an average roundtrip time of 8832.082488 ms, he saw 7616.877558 ms
[ 21:19:33 ]:  I saw an average roundtrip time of 25088.962344 ms, he saw 16833.064914 ms

마지막 2 번의 테스트 후 결과는 약 1000ms입니다.

ISP에 의해 조절되고있는 것 같습니다. 이것은 iOS 게임이기 때문에 사람들은 일반적인 주거 연결을 사용합니다.

패킷 전송 속도를 10 배 느리게 (160ms마다 1 패킷) 변경하면 테스트 시간이 훨씬 오래 걸리지 만 왕복 시간은 지속적으로 낮습니다.

[21:31:27] : 평균 왕복 시간이 55.289109ms이고 69.032727ms를 보았습니다.

따라서 연결에서 낮은 대기 시간을 유지하는 것 같습니다 (ISP에 의해 "처벌되지 않음"). 나는 보내는 패킷의 속도를 줄여야합니다. 이것들은 최대 40 바이트와 같은 매우 작은 패킷이지만 여전히 조절되고 있습니다.

스로틀 링을 피하기 위해 초당 몇 개의 UDP 패킷을 보낼 수 있는지에 대한 지침을 찾고 있습니다! 어디서나 일반적인 지침이 있습니까?

가정용 PC 기반 액션 게임이나 대형 MMO조차도 60Hz에서 패킷을 실행하지 않습니다. 또한 실제로 작은 패킷 크기를 갖는 것이 반드시 좋은 것은 아니며, 작은 패킷 각각은 단순히 보내는 데 큰 오버 헤드가 있습니다.

클라이언트 쪽 보간으로 10Hz 업데이트를 촬영하십시오. 항상 핑 지연이 있기 때문에 이미 보간 중이라고 가정합니다.

더 긴 기간을 커버하기 위해 MTU 크기를 읽고 더 많은 정보를 제공하십시오. 전송 계층의 평균 패킷 크기는 1400 정도이므로 MTU 크기 이상이면 메시지가 분할되어 더 많은 오버 헤드가 발생합니다.

먼저 전체 데이터가 얼마나 큰지 확인해야합니다. ISP는 데이터 그램의 양이나 빈도가 아니라 전송 된 실제 바이트 수에 관심을 가질 것입니다. 초당 최대 60 회 (65507 페이로드 옥텟) 크기의 데이터 그램을 60 회 전송하는 경우 약 30Mb / s 업스트림을 전송합니다. 모든 사람이 그런 종류의 연결을 가지고있는 것은 아닙니다.

IP 헤더의 길이는 20 옥텟이며 UDP 헤더의 길이는 8 옥텟입니다. 각 데이터 그램에 대해 추가로 28 옥텟을 전송합니다.

연결을 최대한 활용하지 않으면 클라이언트 OS, 게이트웨이 (아마도 무선 라우터 또는 케이블 모뎀), ISP, 다른 피어의 ISP, 다른 피어의 패킷과 같이 패킷이 지연 될 수있는 곳이 많이 있습니다. 게이트웨이, 다른 피어의 OS.

아직 사용하지 않은 경우 Wireshark 를 사용하는 것이 좋습니다. 네트워킹 문제를 진단하는 데 매우 강력한 도구 인 . 디버거와 동일하지만 네트워킹을위한 것으로 생각하십시오.

Wireshark를 사용하여 네트워크 트래픽을 진단 할 수있는 몇 가지 방법이 있습니다.

• 무차별 허브가있는 네트워크 장치를 무차별 장치로 설정하여 모바일 장치와 동일한 네트워크의 PC에서 Wireshark를 사용하십시오.

• PC를 무선 게이트웨이로 설정하고 모바일 장치를 해당 게이트웨이에 연결 한 다음 해당 PC에서 Wireshark를 청취하십시오

• 에뮬레이터와 동일한 시스템에서 Wireshark를 실행하십시오.

• 장치 자체에서 tcpdump를 실행하고 (Android에서는 쉽고 iOS에서는 탈옥이 필요함) Wireshark에서 캡처 된 데이터를 읽습니다.

• 똑같은 일을하지만 PC에서 작동하는 간단한 프로그램을 만들고 거기에서 Wireshark를 사용하십시오.

• ... 그리고 많은 다른 사람들

어떤 패키지가 언제 전송되는지 확인하려고합니다. 예를 들어, 지연되기 전에 지연이 발생하면 OS에 의해 제한되고있는 것입니다. 동일한 프로그램의 데스크톱 버전에서도 지연이 발생하면 네트워크에 의해 방해 받고 있음을 의미합니다.

일반적으로 네트워크에 의해 제한을받는 경우 ICMP 유형 4 데이터 그램을 얻어야하며,이를 사용하여 정확하게 제한되는 위치를 확인할 수 있습니다.

결론적으로, 패키지가 지연되는 데는 여러 가지 이유가 있으며 문제를 해결하기 전에 문제가있는 위치를 찾는 것이 좋습니다.

내 가정 중 하나가 잘못 된 것 같습니다. 에 따르면 이 :

GKMatchSendDataUnreliable 모드, 소위 UDP로 전송 될 이미지. TCP로 GKMatchSendDataReliable 모드 이미지 전송. 일반적으로 GKMatchSendDataUnreliable이어야합니다.

에 전송 모드 변경 실제 UDP (즉 것은 GKMatchSendDataUnreliable) 에 나타납니다 초당 60 개 패킷에서 낮은 핑 비율을 유지한다. 내가 다시 Nagles에 맞은 것 같습니다 .

여전히 이상한 동작 (핑 시간이 매우 높은 기간)이 발생하지만 근본 원인 (ISP 또는 네트워크 혼잡)이 확실하지 않습니다.

[ 10:30:33 ]:  I saw an average roundtrip time of 39.908923 ms, he saw 48.437794 ms
[ 10:30:39 ]:  I saw an average roundtrip time of 26.278577 ms, he saw 27.023854 ms
[ 10:30:48 ]:  I saw an average roundtrip time of 23.254163 ms, he saw 24.495182 ms
[ 10:30:54 ]:  I saw an average roundtrip time of 37.333127 ms, he saw 34.780404 ms
[ 10:31:03 ]:  I saw an average roundtrip time of 29.198575 ms, he saw 29.071106 ms
[ 10:31:11 ]:  I saw an average roundtrip time of 49.030299 ms, he saw 48.675459 ms
[ 10:31:18 ]:  I saw an average roundtrip time of 34.031792 ms, he saw 34.698117 ms
[ 10:31:24 ]:  I saw an average roundtrip time of 30.058642 ms, he saw 32.814952 ms
[ 10:31:30 ]:  I saw an average roundtrip time of 53.110438 ms, he saw 54.271453 ms
[ 10:31:45 ]:  I saw an average roundtrip time of 119.693933 ms, he saw 107.616359 ms
[ 10:31:50 ]:  I saw an average roundtrip time of 222.644443 ms, he saw 229.589861 ms
[ 10:31:57 ]:  I saw an average roundtrip time of 166.827070 ms, he saw 167.647724 ms
[ 10:32:05 ]:  I saw an average roundtrip time of 765.356593 ms, he saw 859.600923 ms
[ 10:32:13 ]:  I saw an average roundtrip time of 357.522686 ms, he saw 339.648654 ms
[ 10:32:24 ]:  I saw an average roundtrip time of 1115.639593 ms, he saw 1060.574401 ms
[ 10:32:39 ]:  I saw an average roundtrip time of 175.845995 ms, he saw 171.112166 ms
[ 10:32:44 ]:  I saw an average roundtrip time of 47.262925 ms, he saw 41.987869 ms
[ 10:32:52 ]:  I saw an average roundtrip time of 74.524443 ms, he saw 78.868198 ms
[ 10:33:47 ]:  I saw an average roundtrip time of 20.943917 ms, he saw 21.217377 ms
[ 10:33:52 ]:  I saw an average roundtrip time of 28.944821 ms, he saw 29.303144 ms
[ 10:34:06 ]:  I saw an average roundtrip time of 25.581624 ms, he saw 25.439416 ms
[ 10:34:13 ]:  I saw an average roundtrip time of 25.565568 ms, he saw 25.655267 ms
[ 10:34:18 ]:  I saw an average roundtrip time of 38.609394 ms, he saw 37.462835 ms

나중:

[ 10:38:11 ]:  I saw an average roundtrip time of 40.037623 ms, he saw 43.367524 ms
[ 10:38:21 ]:  I saw an average roundtrip time of 121.222703 ms, he saw 118.855264 ms
[ 10:38:28 ]:  I saw an average roundtrip time of 726.391897 ms, he saw 685.742454 ms
[ 10:38:33 ]:  I saw an average roundtrip time of 60.251207 ms, he saw 57.974503 ms
[ 10:38:42 ]:  I saw an average roundtrip time of 1133.909392 ms, he saw 1124.404501 ms     

산발적이고 파도 속으로갑니다. 패킷 전송 속도를 낮추는 것과 같은 다른 게시물의 제안 중 일부를 시도해야한다고 생각합니다.