Re: [Bluez-users] concurrent calls to RFCOMM connect()

[Marcel Holtmann <marcel@holtmann.org>]

Hi Andrea,

a small comment up-front. Top-posting is not a good way of getting my
attention. Check http://www.bluez.org/lists.html

> I have been reading and thinking on this issue but need some more
> clarification. After reading RFCOMM documentation on BlueZ's site I
> wasn't able to get it clear, so I set up this simple experiment: usign
> bluez rfcomm utility I try to connect to an unavailable (powered off)
> device.
> 
> $> rfcomm connect 00:01:95:07:30:EA
> 
> It takes about 20 seconds to timeout with a reasonable "Host is down"
> error. This means to me an internal bluez rfcomm socket timeout,
> correct?. In the meanwhile, if I make another call to rfcomm connect,
> I get "Device or resource busy". I understand this as: "there is no
> way other than serializing connection attempts". Is this an intrinsic
> behaviour of the rfcomm implementation or might it depend on the
> specific hardware I use? I did this test on my Ubuntu 2.6.20 kernel
> with rfcomm ver 3.9.

It takes 20 seconds, because that is the page timeout of your local
hardware. You can change it with "hciconfig hci0 pageto". You can also
play with the link supervision timeout to faster detect a link loss.
Please remember that a shorter value also has disadvantages.

> In your reply to my original post (attached) you said that newer
> kernel are supposed to do some queuing on the request... Does it mean
> that my test should have behaved differently?

It serializes connection attempts to different remote devices. If you
try to connect to the same remote device (by opening the same TTY twice)
then you are out of luck. The kernel is not doing anything here. And why
should it? If it just failed a few milliseconds ago, why should the
attempt succeed now. It might be, but it is unlikely and blocking the
baseband with another page attempt makes no sense here.

> My concern is that I have to be able to keep four devices connected
> and implement some sort of reconnection scheme when I loose the rfcomm
> link. It is important to understand if I have to estimate a worst case
> latency on devices reconnection of about 20 seconds (the connect
> timout) multiplied by the number of unavailable devices (if I just
> implement some sort of round-robin reconnection attempt loop and I
> happen to start from the very-wrong device in the list).

You need to read the specification since clearly you are guessing here
behavior. The various timeouts can be configured. Or maybe get a book
that explains the basics behind the Bluetooth radio.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users