Re: [RFC] Auto Connections

Hi Arun,

On Mon, Mar 21, 2011 at 10:55 AM, Arun K. Singh [off-list ref] wrote:

Hi Claudio,

quoted

quoted

quoted

It is time to get opinions from some gurus!

We need to implement automatic connections to implement the Profiles.
At the moment BlueZ supports only dual mode adapters, as consequence
BlueZ needs to start the LE connection. IMHO, it is better to leave
the responsibility to the controller, implementing "selective"
connections will only introduce more code without concrete benefits.
Configuring the controller to autonomously establish connections seems
to be the right approach to proceed.

This topic is NOT about StartDiscovery() + CreateDevice.
StartDiscovery uses active scanning and CreateDevice uses direct
connection establishment. We need a mechanism to automatically connect
to "trusted" devices or devices flagged as "AutoConnect".


My initial idea is: change the LE server socket to report
outgoing(host initiated) connections through the server socket.
Awkward?
To achieve that we need to manage the LE Create Connection(using
whitelist) in the kernel, extend the management interface to control
devices in the whitelist, change the LE Connection Complete Event
handling to get the Role properly.
Pros:
- Controller manage connections
- Flexible to support  connections to "trusted" resolvable address and
passive scanning
- Only one "flow" for the connections: LE server socket
- Maybe we could hide resolvable address from the userspace, mapping
it directly to public or static random

This approach have a lot of advantages. It seems the best option to me.

quoted

Cons:
- Risky

Define risky here.

More code in the kernel, more time to get the code upstream,
additional verification to avoid insufficient resources when scanning
and connecting, but to me it seems the best approach.

to Jaikumar:
The profiles will indirectly manage the connections providing
informations such as connection parameters(interval, window, ...) and
addresses, but the kernel needs to centralize/manage the connections.

As per section 9.3.8, a host can still perform direct connection
establishment procedure
by telling controller to "ignore the White List and process connectable
advertising
packets from a specific single device specified by the Host". Wouldn't this
be same
as letting the host[read profiles] directly manage connections?

There are four Connection Establishment Procedures: Auto, General,
Selective and Direct.
CreateDevice/CreatePairedDevice will use Direct. But after pairing or
create device("known" devices) we need a more transparent procedure. I
am not saying that we will implement straitly Auto procedure, we will
also need to handle the resolvable address, a hybrid approach seems to
be more appropriated.

 We could use Direct procedure, managing(serializing) the connection
establishment implementing logic in the kernel or userspace for the
"known" devices. However, I prefer to transfer the responsibility to
the controller. If I choose connections using whitelist, how the STE
controller prioritizes the advertises? Does directed advertises have a
higher priority?

quoted

We can't allow the profiles to control the connection directly, a
remote can implement more than one profile, maybe with different
constraints.

under direct connection establishment procedure, it should be possible for a
host
to establish connection with a remote peer device with host selected
connection
configurable parameters. Why should we deprive a bluez host of establishing
such a connection...
Or did I miss something here?

At API level, what is the benefit of exposing this option to the API users?

Some profiles define the recommended connection parameters, there is
also the Slave Connection Interval Range AD type that may be used to
in the  connection establishment.

BR,
Claudio

Thanks,
Arun