Re: [Bluez-devel] DBus interface - determining whether a device exists

[Matthew Garrett <mjg59@srcf.ucam.org>]

On Thu, Aug 17, 2006 at 02:56:00PM +0200, Marcel Holtmann wrote:

> You must understand that you can't do this with Bluetooth. If you wanna
> know if you can connect to a device then the baseband has to page the
> other device. This is an expensive operation and it will stall all
> ongoing paging or inquiry operations. So in general you don't wanna do
> this unless you are in a special environment and know what all users are
> doing. For the normal desktop case we simply don't know this. So it is
> not a good idea. Not speaking of the higher power consumption of such
> operations.

In this specific case, it's done at login time. That's a point where we 
/do/ know whether or not there are any existing connections (I'm 
ignoring the multiple user case, because the DBus API doesn't really 
deal with that at the moment anyway).

> You also have to think about moving targets. For example at an airport
> where a lot of devices will pass you. Trying to page them and waiting
> for a page timeout is an even more expensive operation.

Sorry, possibly I should be clearer about the behaviour I'm talking 
about here.

Imagine the case where a user has bound a set of headphones. They've 
chosen to make them their default audio device. At login time, we wish 
to attempt to reconnect to the headphones. It would be nice to be able 
to do so by checking whether the device exists or not first.

At the moment, the method for doing that would appear to be to store the 
following information:

1) The bluetooth address
2) The fact that it's a set of headphones
3) Whether it uses rfcomm or l2cap

and then at login time do service discovery (because we don't know 
whether the channel may have changed) and attempt to set up a 
connection. The alternative would be to store:

1) The bluetooth address

and then at login time attempt a baseband connection to the device. If 
it exists, then we can do service discovery and worry about the other 
pieces of information. If we can't set up a baseband connection, we 
don't need to bother.

The second approach strikes me as simpler than the first approach, but 
it requires the ability to set up that baseband connection which you're 
clearly unhappy with. Is the first approach how I should be doing this?

> So what you actually want is to set a device in periodic inquiry mode
> and then make it constantly report devices in range. 

Well, no - I don't actually care what happens to the device after that. 
If the user moves the device out of range, or if the user logs in 
without the device being switched on, then it's acceptable to require 
the user to manually reenable the device. But it's entirely reasonable 
for the user to say "If the device is switched on when I log in, please 
automatically connect to it". That's the problem that I'm trying to 
solve. Unlike periodic inquiry, this wouldn't result in any significant 
increase in power consumption. It's a one-shot-per-session thing.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel