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

["Andrea Galbusera" <gizero@gmail.com>]

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