|
Chip,
The issue that you mention arises even when there is only one iPhone connected to your peripheral-based app.
On this single iPhone, multiple apps could run concurrently and access this same peripheral-based app.
iOS currently solves this by multiplexing all requests from the different apps over the same connection.
You cannot distinguish the different apps from your peripheral-based app, and you are also not able to detect when
one of the apps disconnects or connects, as this information is simply not available. There is no way to detect if you are
talking with a single app or multiple apps at the moment. And it is also the reason why you cannot terminate a link
with a single app from the peripheral side, and why you can only send disconnect requests from the central (whose
executions are delayed until every other app also closes the connection).
Because you already have to deal with potential concurrent access from different endpoints anyways, it makes sense
to extend the Bluetooth Core Spec at this point and support also multiple concurrent physical connections.
One alternative would be to restrict access to only a single app on the central device at a time. However, this
would possibly cause bad user interaction, as you may not be able to discover a peripheral because a backgrounded
app is still connected to it.
iOS 6 does not strictly conform to the Bluetooth Core Spec here but provides an approximation which is acceptable
for various use cases.
Etan
This question may be more pertinent to a Bluetooth SIG group, which I am going to flow up with, but I thought it might be of interest to this group as well.
The issue deals with adherence to the 4.0 spec for allowing a peripheral/slave to be accessed concurrently by multiple Central/Managers.
I have coded a CBPeripheralManager based peripheral and found that it supports multiple concurrent connections from different Central devices. There is sufficient information in the CBATTRequest
which identifies the requesting Central that intelligent handling of the server based resources (e.g. the immediate alert) can be managed effectively. Generally it is just a matter of storing transaction records based upon the
requesting Central.
But, in reading the Bluetooth 4.0 spec, I found the following information .. my red highlight.
================
From Core_V4-1.0 [ Volume 1]
3.3.2.1.3 Topology
An LE piconet channel can be shared by any number of LE devices, limited only by the resources available on the piconet master device. Only one device is the piconet master; all others being piconet slaves. All communication is between the master and slave
devices. There is no direct communication between slave devices on the piconet channel.
There is virtually no limit on the number of logical transports that can be sup- ported within a piconet. This means that there is no theoretical limit to the num- ber of Bluetooth devices that share a channel with the master.
At present an LE device is only permitted to belong to one piconet at a time.
================
So a Central/Master can connect to multiple peripherals but a slave can be connected to only a single Master at one time (else it would be in more than one piconet).
The iOS platforms enable peripherals to be concurrently accessed by multiple Masters (my empirical work), will doing so effectively result in the peripheral device being non-compliant to 4.0 spec?
-Chip
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
|