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

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

[Andrea Galbusera]

Hi all,
I'm planning to write an application handling communication with four
bluetooth devices, each with its own BT address. I was thinking to
design it with four parallel threads and use rfcomm sockets API.

The common thread function will start connecting to the appropriate
remote device by allocating a socket and calling connect(). Do I have
to consider any particular syncronization issue between the threads?
Is this approach reasonable or not?

I found posts in the archives about connect() returning EBUSY. This
has to be an   error code specific to RFCOMM sockets. When is it
supposed to be raised? Is it something I have to take into account in
my scenario?

TIA
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Marcel Holtmann]

Hi Andrea,

> I'm planning to write an application handling communication with four
> bluetooth devices, each with its own BT address. I was thinking to
> design it with four parallel threads and use rfcomm sockets API.
> 
> The common thread function will start connecting to the appropriate
> remote device by allocating a socket and calling connect(). Do I have
> to consider any particular syncronization issue between the threads?
> Is this approach reasonable or not?
> 
> I found posts in the archives about connect() returning EBUSY. This
> has to be an   error code specific to RFCOMM sockets. When is it
> supposed to be raised? Is it something I have to take into account in
> my scenario?

depending on how which kernel you use, this might work. Older kernel
didn't queue the ACL link requests and so you saw problems.

Regards

Marcel



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Andrea Galbusera]

Hi Marcel,

On 10/17/07, Marcel Holtmann <marcel@holtmann.org> wrote:
> > The common thread function will start connecting to the appropriate
> > remote device by allocating a socket and calling connect(). Do I have
> > to consider any particular syncronization issue between the threads?
> > Is this approach reasonable or not?
> >
> > I found posts in the archives about connect() returning EBUSY. This
> > has to be an   error code specific to RFCOMM sockets. When is it
> > supposed to be raised? Is it something I have to take into account in
> > my scenario?
>
> depending on how which kernel you use, this might work. Older kernel
> didn't queue the ACL link requests and so you saw problems.

I'm working with >2.6.17 kernels and >2.25 bluez. Since the
application should run also on some embedded device with 2.6.17 and
bluez 2.25, it is important for me to know in advance if the
architecture I have in mind is feasible or not.

If my kernels are affected, is the EBUSY problem something related to
the connect() call only or do I have to expect more general problems
in using threads for communication over BT sockets?


Thanks
Regards,
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

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

[Andrea Galbusera]

Hi Marcel,
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.

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?

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).

Please help me understanding if I need to update any of the involved
software components or if I'm missing any important point on the
topic. I'll be pleased to read any clarifying document on this.

TIA. Regards,
Andrea

On Oct 17, 2007 3:20 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Andrea,
>
> > I'm planning to write an application handling communication with four
> > bluetooth devices, each with its own BT address. I was thinking to
> > design it with four parallel threads and use rfcomm sockets API.
> >
> > The common thread function will start connecting to the appropriate
> > remote device by allocating a socket and calling connect(). Do I have
> > to consider any particular syncronization issue between the threads?
> > Is this approach reasonable or not?
> >
> > I found posts in the archives about connect() returning EBUSY. This
> > has to be an   error code specific to RFCOMM sockets. When is it
> > supposed to be raised? Is it something I have to take into account in
> > my scenario?
>
> depending on how which kernel you use, this might work. Older kernel
> didn't queue the ACL link requests and so you saw problems.
>
> 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

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

[Marcel Holtmann]

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

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

[Andrea Galbusera]

Hi Marcel,

On Nov 26, 2007 6:36 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> a small comment up-front. Top-posting is not a good way of getting my
> attention. Check http://www.bluez.org/lists.html

You are obviously right! I apologize to you and other users of the
list for the inconvenience. That was accidental and was not intended
as a way to catch more attention. I understand that some of my
questions may sound silly to you and other bluez developers, but I
don't have a wireless communication background and I'm trying to
approach bluetooth from the application level.

> 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.

I will search more on these timeouts and the pro/cons of changing
them. Maybe tuning them will suffice.

> 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.

My question was not clear enough... In my test I try to connect to a
different remote address while in progress with the first one (both
powered off). I do it like this:

Terminal 1:
$> rfcomm connect 00:01:95:07:30:EA

Terminal 2 (while the first attempt is in progress):
$> rfcomm connect 00:01:95:07:30:40
Can't connect RFCOMM socket: Device or resource busy

Does it mean my kernel and/or my bluez-utils are too old to queue
connection attempts?

> 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.

I'm going to follow your suggestions, even if I believe the
specification is too intricated for me. Maybe a book is a better
choice. Thanks for patience.

Regards,
Andrea

-------------------------------------------------------------------------
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

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

[Marcel Holtmann]

Hi Andrea,

> > 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.
> 
> My question was not clear enough... In my test I try to connect to a
> different remote address while in progress with the first one (both
> powered off). I do it like this:
> 
> Terminal 1:
> $> rfcomm connect 00:01:95:07:30:EA
> 
> Terminal 2 (while the first attempt is in progress):
> $> rfcomm connect 00:01:95:07:30:40
> Can't connect RFCOMM socket: Device or resource busy
> 
> Does it mean my kernel and/or my bluez-utils are too old to queue
> connection attempts?

I think your kernel is too old, because we fixed that. However the
kernel only queues the attempt. It won't make it faster since we can't
serialize the baseband/radio.

> > 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.
> 
> I'm going to follow your suggestions, even if I believe the
> specification is too intricated for me. Maybe a book is a better
> choice. Thanks for patience.

There exist a bunch of books that are good enough. Actually the might be
even better then the raw specification document.

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

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

[Marco Pracucci]

Hi Marcel,
>>> 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.
>>>       
>> My question was not clear enough... In my test I try to connect to a
>> different remote address while in progress with the first one (both
>> powered off). I do it like this:
>>
>> Terminal 1:
>> $> rfcomm connect 00:01:95:07:30:EA
>>
>> Terminal 2 (while the first attempt is in progress):
>> $> rfcomm connect 00:01:95:07:30:40
>> Can't connect RFCOMM socket: Device or resource busy
>>
>> Does it mean my kernel and/or my bluez-utils are too old to queue
>> connection attempts?
>>     
>
> I think your kernel is too old, because we fixed that. However the
> kernel only queues the attempt. It won't make it faster since we can't
> serialize the baseband/radio.
>   
In which kernel version did you add this feature?

Marco Pracucci


-------------------------------------------------------------------------
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

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

[Marcel Holtmann]

Hi Marco,

> > I think your kernel is too old, because we fixed that. However the
> > kernel only queues the attempt. It won't make it faster since we can't
> > serialize the baseband/radio.
> >   
> In which kernel version did you add this feature?

it is part of 2.6.19 and later.

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