RFCOMM Event Ordering
RFCOMM Event Ordering
- Subject: RFCOMM Event Ordering
- From: James Blair <email@hidden>
- Date: Fri, 19 Sep 2008 12:38:54 -0500
Hello:
I have some code that communicates with a Bluetooth device using the
RFCOMM protocol. The communication is very ordered -- that is, I
typically send a command, then, wait for a response from my device, and
then send the next command (as opposed to receiving data at unpredictable
intervals from the Bluetooth device). I've created a callback and
registered it using the
IOBluetoothRFCOMMChannelRegisterIncomingEventListener function from
IOBluetoothUserLib.h. This has been working fine for me since OS X
10.3.9.
However, we recently noticed some strange behavior on newer MacBook Pros
running OS X 10.5 (with a particular Bluetooth chipset? or maybe dual
core?). Digging into the problem, I discovered the root cause was that
RFCOMM events were arriving in my callback in an order I didn't expect.
Typically the exchange goes something like this:
1. write data
2. receive kIOBluetoothRFCOMMChannelEventTypeWriteComplete
3. receive kIOBluetoothRFCOMMChannelEventTypeData
4. read data
But in this situation, the order was:
1. write data
2. receive kIOBluetoothRFCOMMChannelEventTypeData
3. receive kIOBluetoothRFCOMMChannelEventTypeWriteComplete
4. read data, but with buggy behavior
That seems counter-intuitive -- how can the response data be ready before
the write has completed? I expected that a search through the
documentation would find either (a) a guarantee that a write event will
always complete before the new data event occurs, or (b) a warning that
events can arrive out of order, so I should code carefully. Unfortunately,
I didn't find any inforamtion about event ordering. (Closest was
http://developer.apple.com/documentation/DeviceDrivers/Reference/IOBluetooth/IOBluetoothUserLib/CompositePage.html.)
The happy ending is that we were able to resolve the problem just fine by
being more careful about how we process the different events. But this
seemed like strange enough behavior that I should expose it to a wider
audience, if for no other reason than to serve as a caution to other
developers.
James Blair
National Instruments
www.ni.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden