Re: the Zell solution ... it works!
Re: the Zell solution ... it works!
- Subject: Re: the Zell solution ... it works!
- From: JP May <email@hidden>
- Date: Tue, 10 May 2011 21:12:12 +0200
Hi Mark,
> I'm not sure what you mean by "realtime" here,
I mean realtime control (via some sort of moving device: a knob, mouse, Wii controller or similar) of computer things - via wireless.
Hence, exact examples of this are your wireless mouse, all Wii games, and iPhone device-to-device games such as "Chopper" "Scrabble" etc.
> 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.
You know, at first I thought "oh UDP". the interesting thing is though if you try both, it's just not clear that there's any advantage at all.
if the network craps up, or a machine craps up, or something in your code craps up, or any of the other stuff in networking that can crap up does crap up, it's not clear that UDP v. TCP gives any advantage, try it and see.
We did and the "academic" if you will answer, it's far from clear-cut that that is the right answer. I just dunno.
I get a feeling you just have to manually create your own protocol below either of those, in a newish way.
> 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,
Say you have a wireless controller for flying an aircraft
(I mean an actual aircraft, a Boeing 747 ... let's say the pilot's "Manette" n the arm of his chair, is wireless to the flight deck computers).
So say you have that -- what would you send? Only updates? Continuous everything? Or ?
I just don't know man. It's tough!
> or that you flush data at half or 1/4 the period of your maximum acceptable latency.
What do you mean by Flush here.
> This will give you the chance to re-send data if your last message wasn't acknowledged in time.
I just dunno if that's the strategy to adopt. it's tough. Maybe betterto forget about it -- after all, the knob is now in a different position, the human has it somewhere else. Do we care where it was?
And there are just so many special and situational cases.
> 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).
I believe you're right. We just did some extensive testing driving a car (computer car!) where you could vary the Hz at any time.
amazingly, down to about 18 hz per channel it still honestly feels flawless.
We were able to run it at 500 hz (!!!!!) (I write lean code!) with the fastest ipad/fone hardware,
and as a player I could not really say there is much difference. MAYBE 70 or so, I got an impression, is about the highest you could perceptually feel it is better than lower speeds. It's really interesting.
> 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.
Right.
I just dunno though. In practice do you EVER get one of those sort of theoretical lost packets (whgere everything is suddenly nice again) as UDP handles so well?
I've never seen it !
there's always some CATASTROPHIC situation where all the packets stop for large fractions of a second, or even more than seconds ..
It's more about trying to aboid those, I just don't know.
how come your Apple Mouse works so well? What the hell is the secret I don't know.
> 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.
An excellent point.
("|I believe the only realtime-like behavior in the system is given to CoreAudio..." and maybe to the pointing devices??)
beats me!
My latest ZELL TECHNOLOGY networking is wonderous, but, it's not like a mouse, I don't think ... I dunno.
Anyway, I want to get in to adaptive framerates,
to counter problems like too many people joining a game, you have to throttle down the handsets in that case (I guess). (If you reach apparently about "500hz" on an iPad2 !)
Also depending on how crap the person's wifi hub is.
Then again, is this even a valid overall-strategy? (trying to go as fast as possible all the time.)
is it better to determine (psychologically, just as you said) the lowest possible Hz rate and then ........... ONLY use that? after all, why Waste Risk with any faster rate ever? I don't know.
So I was just wondering if there were lots of "adaptive framerate libraries" around already ... I guess not !
Fatty _______________________________________________
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