Re: Surely someone knows this ?! Jens knew
Re: Surely someone knows this ?! Jens knew
- Subject: Re: Surely someone knows this ?! Jens knew
- From: J P May <email@hidden>
- Date: Wed, 31 Mar 2010 09:05:23 +0200
I don't know the data rate of Bluetooth, but it's probably around a
megabit. At that rate, it sends a byte about every 10 microseconds.
(FWIW, someone on the list mentioned bluetooth has some sort of hard
limit of "652 milliseconds" per *message* - I know absolutely nothing
about it. I'm sorry, I deleted your email, 652 milliseconds person!
:) )
http://progtutorials.tripod.com/Bluetooth_Technology.htm#_Toc41989845
Chances are you are that's not a significant amount of time for your
application.
I guess the GameKit paradigm is the overwhelming factor.
The GK wrapper may be 25kb. Or it may be four bytes (some sort of
device code once it is established).
For all I know, GK opens a proper session, like a telnet session to
put it in simple terms. Or it may be a one message at a time
protocol. Nobody knows.
The GK "unreliable" mode, I *assume* uses some sort of
don't-bother-checking paradigm, at some level (but who knows, that
may be wrong)
Fortunately, you've given us the realisation that GK is tightly held
and there's unlikely to be info on it - explaining why it doesn't
mention this info right there in the GK-for-beginners manual
So, it's all settled, thanks
Where bytes do become significant is when the data payload overflows
the size of a packet and has to be split across two. If you're using
an unreliable packet-based transport (like UDP), messages that have
to be split across physical packets are inefficient because, if
either of the packets gets lost, the entire message is considered
lost and has to be resent. This can cause delays and wasted
bandwidth on lossy wireless networks.
understood, indeed, that is one of the reasons I was wondering about
the question!
(Again, I don't know the size of a Bluetooth packet; on Ethernet
it's ~1500 bytes.)
Huh, I did not know that, 1500 bytes...
Easy network APIs are great ("Simple things should be simple" -Alan
Kay) but they don't work for every situation. He-man networking
still applies when you run into more complex scenarios or have to
push the limits of throughput. I found this out when I implemented
audio streaming a few years ago. :-P
"real" network programming is one of the few He-man areas remaining!
no normal human can actually program audio streaming, we know you're
just making it up ;-)
You know, much as Apple has given us GK which "makes bluetooth
extremely simple" .. you'd guess that next they will do something
XYZ that "makes WiFi extremely simple" .. perhaps that will be next?
-Jens
_______________________________________________
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