We have today at the Lab decided that iPhone GameKit is not reliable and mature enough to be used for our application. Keep in mind this is research, and it effectively only has to be working to record a short paper video. But still, there was no guarantee that it works. Here is a summary of the arguments:
– GameKit offers a latency significantly lower than WiFi, about 1/3rd to 1/5th (150+ms to 30-50ms).
– Bluetooth enables Ad-Hoc setup of a PAN, which is great for parties and other get-togethers.
– For Wifi and Bluetooth, the (hypothetical) connection speed is limited by the upload, in both cases 60KiB. Hence, it would make no difference bandwidth wise (except for the zillions of connection stalls).
– The more devices are added, the more unreliable GameKit gets. I’ve so far tested with up to 4 devices, and each time we added a new device, the situation got significantly worse.
– It breaks too easily. Once it’s broken, there is no way to recover (unless we re-connect, which may take a longer while).
– It is very hard to tell exactly when it broke, programmatically. Normally no disconnect message is sent, it just doesn’t transmit/accepts any data anymore. When sending large chunks of data, socket buffers are usually filled up so we have to work with a time-out in that case.
– The console debug output is very annoying. To disable it, we can pass error:nil to the send functions. But then we can not parse the error codes anymore. If an NSError* is passed to the error: parameter, it will print the error to stdout.
– Sending of a lot of data in a multi-device setup is a royal pain in the whoopie cake.
– It’s not cross platform (and we have some G1/G2 devices, too)
– It’s reliable, even with a lot of data and many peers.
– It’s debug-able
– It’s cross platform
– not ad-hoc
– 3-5x higher latency
I’m hoping for tomorrows Media Event and the rumored release of 3.1 to resurrect my GameKit efforts (I still have the Limbic project going on, and I may use it as a testbed for further endeavors). But for now, no more GameKit. 🙁