Re: the Zell solution ... it works!
Re: the Zell solution ... it works!
- Subject: Re: the Zell solution ... it works!
- From: Mark Pauley <email@hidden>
- Date: Mon, 9 May 2011 12:36:30 -0700
> An interesting broad question is, extremely simply:
>
> "How is one supposed to do realtime device-device networking on iOS?"
>
> It seems to me this is just an open question that's never really been answered.
>
> Are you supposed to use something like AsyncSocket (ie the CF layer) and apply all necessary tricks? Is that actually just newbie nonsense, and the answer is "Of course you'd have to work at a BSD sockets level for realtime device-device comms, everyone knows that"? Is GameKit the answer (is it now tuned for such situations - who knows?) Do you have to adopt some even lower (?) level below sockets?
I'm not sure what you mean by "realtime" here, but your best bet would be probably UDP networking via CFSocket if you don't care about losing data.. Asynchronous TCP networking via CFSocketStream if you do care about losing data.
As far as 'realtime' networking goes, the question is: what is your maximum acceptable latency and what is the probability that your packet is lost? I would generally recommend that you send data when an event occurs, or that you flush data at half or 1/4 the period of your maximum acceptable latency. This will give you the chance to re-send data if your last message wasn't acknowledged in time.
Based on my understanding of human perception (from some electronic music theory class in college), a good range for your maximum latency is between 15 and 30 milliseconds. That puts you into the 60Hz to 30Hz range (so your value of 40Hz is right on). If you could crank your rate down to 30Hz and resend when your message wasn't acknowledged by 10 or 15 milliseconds, you should be able to handle the odd packet loss before the end of the current cycle with no problem. I'm speaking about UDP here, TCP doesn't give you a way to change the retry timeout.
Note that there are no guarantees here. iOS, like MacOS is not realtime in the true sense. Your process may be swapped out for an indeterminate amount of time. I believe the only realtime-like behavior in the system is given to CoreAudio.
>
>
>
>
>> For background as to why this is important, you should watch WWDC 2010 Session 201 "Developing Applications that work with iPhone OS Accessories"; it's packed full of useful tidbits on Bluetooth, and covers this issue in depth.
>> <http://developer.apple.com/videos/wwdc/2010/>
>>
>> S+E
>> --
>> Quinn "The Eskimo!" <http://www.apple.com/developer/>
>> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
>
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Macnetworkprog mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden