I have a network 2 player dice game that works wonderfully....
1) on my local LAN
2) playing people in the same city (distance 30 miles)
3) playing from free Wifi at the McDonalds to my home LAN (distance 5 miles)
4) playing from free Starbucks wifi to my home LAN (distance 5 miles)
5) connecting one device to a VIRGIN MiFi card to my home LAN.

but seems to "choke" within 5 minutes..
1) playing someone 900 miles away
2) playing someone 3000 miles away..

When I say choke, i dont really know what the problem is. It appears as though some command packets are missing, or received multiple times. Dont know yet. The other side people are non technical, and I was lucky just to get them to test for the few minutes.

I think u get the point.

Of course it must be my code.

My dream.. recreate this issue consistently locally. I thought using the Virgin 3G MiFi card would do it..but it works flawlessly with it.

Some background:
iphone app
using GameCenter, TCP reliable packets.

Im ASSUMING since im using GameCenters reliable packet delivery, i should not be missing commands, getting duplications, or out of order packets.
But i might get a stall in commands, then a flurry of commands all at once.

I tried to simulate this by queuing incoming commands, and holding them for a bit. then releasing them all at once.
The game ran perfect. (im combing the code again, hoping i did something wrong..but dang..the code is so simple...)

Heres my thinking. let me know if im high on crack.

GameCenters reliable packet delivery is not that reliable. At close distances, the chances of corruption are extremely low, which is why i SEEM to get perfect execution within close distances.
If its not completely reliable, it could still happen, given enough time. On my local LAN, multiple iphones connect,play,disconnect, over and over, overnight. all run perfect.

When the distance is increased, there are more chances of packets missing, retrys, etc..which is why those people are getting errors and the game is getting out of sync.

Another idea was to have the iPhone connect to a proxy server, in some place far, lets say Costa Rica, creating a large round trip. But realized i need to find a proxy server that will route my GameCenter UDP packets, and not just HTTP/HTTPS. Plus that proxy needs a certificate for GameCenter. Slim chance.

How can i recreate what is happening so i can debug locally?

Assuming the GameCenter reliable packet delivery works properly (google didnt show any signs of other people having this issue), then the only characteristics i can see is the stall of commands, and then the flood of them coming in at once.

Im a network newbie, so slap me silly with whatever you got!

From Apples Website: here are the ports used for GC.

Ports to open
If the Wi-Fi network router that you are connected to uses a firewall or security software to restrict Internet access, contact the network administrator and refer to this technical article. To use Game Center on a restricted Wi-Fi network, port forwarding must be enabled for ports 443 (TCP), 3478-3497 (UDP), 4398 (UDP), 5223 (TCP), 16384-16387 (UDP), and 16393-16472 (UDP).

Seems like an awful lot of ports to have open for a simple game... any chance you could change your underlying network code to use a different library?

Thats always a possibility..but its almost there, everything works at "close range"..its just when connecting at a "distance"
Plus its Apples Game Center. Used by many many, and in production code by many many apps.
If it was some library made by a few, for use by a few, then yea..i might ponder switching network libraries.


Game Center supports a lot of features, such as Peer2Peer Bluetooth, local Wifi, and Voice Chat, the "lots of ports" could be used for Voice Chat, since you can talk to individuals, sub groups, or broadcast voice to all.


i just need to find a way to debug this "distance" bug.

What characteristics does latency have on packets in TCP?

+ Reliable
+ In-order
+ No Duplicates
- Slower - due to retrys, and waiting back for acknowledgements.
- stalls, and floods of data at once (when all the large fragments complete) <=== this is just my guess
- Fatter headers when compared to UDP

can anyone add to the list? Maybe something might spark an idea in me head.

[quote name='ApochPiQ' timestamp='1310160097' post='4832933']
Seems like an awful lot of ports to have open for a simple game... any chance you could change your underlying network code to use a different library?

I think Game Center still works through a regular NAT gateway -- what they call "port forwarding" probably means "don't filter these ports."


To test with real latency, you can try two pretty simple options:
1) Host on a virtual server somewhere. Amazon Japan ECC? Some European cloud provider?
2) Use a VPN in some distant country. anonine.se ? Make your machine, and perhaps the server, part of that VPN.


Btw: if you're using TCP, then the chance of corrupted data making it to you are pretty much nil. The chance of it happening repeatably is absolutely nil.
It's more likely that you're doing something wrong, like not treating half-received packets right (assuming you use a raw TCP socket -- I haven't seen the Game Center API, so maybe it does this for you)
[/quote]

Ooo! a VPN! That could do it! That should route everything properly! and hopefully far away.

For my data packs, I added a "magic number" at the end of all the data sets to "verify" that all the data was complete. That assert never triggered.

Oh and its definitely my code. Im blaming myself until proven otherwise

thanks for popping VPN in my head..its giving me another road to follow.

Ok issue has been fixed.. the game works wonderfully everywhere (that i tested

I was using TCP, and based on the previous message from hplus where he states that corrupt data is pretty much nil, i ruled out that packets were missing, or duplicated.
HPlus: When you say "pretty much nil", do you mean ABSOLUTELY nil? or have u had it happen to you? or heard stories that it happened to someone once before? im just curious.

So just latency was causing the bugs..


Some things i tried to simulate the distance.

On outgoing packets, i buffered them, and randomly let the flood gates open and close. - simulate a bad network, packets being held up
On incoming packets, i buffered them, and randomly let the game get access to them. - simulate a bad network, packets being held up.
in the "game loop", i slowed its processing down randomly from 1fps to 60 fps. - simulate slow iphones, or devices that were in a busy state.

the packet delay code, would delay from 0 frames, up to 1.5 seconds.

It was during one of these delays, where the controls should have been disabled (because its the next guys turn), but wasnt.
so as it was waiting for a packet (which is delayed), you can still send commands to the other device.

Whats worse, is that even though the controls were disabled on the local persons device, the network command packets were still being sent to the other device. Doh!

So when running on a high speed network, without any delays or slowdowns, the window of time to send the rogue commands was pretty thin. So issues never happened.
When the delays were added, the window is wide open, causing these freak issues.

Tested across country distance, using the slow EDGE network, driving around.. perfect.. game runs like its on a cable modem.

thanks to everyones comments, they really do help stir the brain.

Think of it this way. TCP is used for basically all web traffic, email, file sharing, and so on. When was the last time you downloaded a web page and it was missing a chunk, or had spelling errors that went away on refresh due to corrupted TCP data?

TCP is an extremely robust protocol. In practice, you will not see dropped or corrupted packets. There are theoretical ways to screw it up but without extremely contrived circumstances even the theoretical possibilities are slim and very, very difficult to create. So, for all practical purposes, you can rely on data arriving, in order, uncorrupted, at some point. The only thing you really have to deal with is backlogging.

awesome..thanks for the clarification. i got a big bump in XP!