Re: [Bluez-users] problem in making multiple connections using single bluetooth adapter using bluez

[Marcel Holtmann <marcel@holtmann.org>]

Hi,

> Obviously, BlueZ didn't learn to deal with more than one connection at
> the same time yet. They are still thinking that everybody has a
> desktop computer with KDE (or Windows, as dbus being a derivate from
> gtk, is specially designed to be platform independent) and just a
> single cellphone or PDA at home. Of course, large companies like Nokia
> are not really affected by these problems, as a cellphone is so small
> that it can't deal with much more than one thing at the same time
> anyway. But this may change in some future.

that is FUD. BlueZ can deal with as many connections as the chip allows
us to establish.

> So your only choice is to not use libbluetooth. Marcel is right when
> he says that this implies a lot of work, as you will have to implement
> each protocol layer yourself. But as these are quite badly designed in
> BlueZ, there is really no fix for it. If the BlueZ developers had a
> different way of dealing with users (just look at their answers) the
> many thousands of hours of work we are doing each one on his own could
> go into this project. So, we are alone here. Your choices like mine or
> anybody else's who is trying to serious work with bluetooth, is either
> to give up or to do the work.

Badly designed protocol layers. We provide BSD socket based access to
them which is one of the most intuitive interfaces. Did you ever looked
at other stacks and their API?

> But be aware, that re-writing the protocol stack may not be
> enough. I've done so and am having bad troubles because BlueZ
> developers think that an exclusive usage over a socket can be
> implemented by the concept of a raw socket. This is not true. Even
> using raw sockets the kernel will interfere in your programming,
> meaning that it is quite possible that we will have to replace also
> the kernel modules, which would make 100% of BlueZ code unusable. Not
> regulating mutually interfering accesses to one and the same ressource
> is pure Windows philosophy, where each program, starting with
> kernel.dll thinks it owns the complete device. Raw sockets allow to do
> low leve things, but they don't guarantee that someone else wont undo
> what ever my program has done a second earlier. Even if this someone
> else is the kernel herself.
> 
> I've suggested the use of an exclusive flag with the HCI sockets, when
> Marcel answered, that the kernel does NOT interfere when I open that
> socket in raw. This is just not true. Marcel (who should know as he
> wrote this monster) asked what exactly happens. Here it is:
> 
> If your program is already active and you plug in an USB bluetooth
> dongle, the kernel issues several informational queries to the
> device. It needs to do so, as a raw socket doesn't imply that there
> couldn't be more than one processes accessing the same device (there
> is no exclusivity), while a second process might want to use a cooked
> socket. In my case, I know that there will be no other process,
> specially not hcid or dbus, but the kernel doesn't, and still issues
> these commands. Thus, I need to expect anything to happen, just for
> the USB dongle having been plugged in. This raises the level of
> complexity of my program by a power of magnitud. Also, Marcel himself
> said, that whenever a major version number is increased, we can not
> trust that the behaviour wont change incompatibly with the previous
> version (besides the use of dbus and apparently the inability to
> multitask). Did anybody see any reasoning why dbus is defended so
> stiff neckedly? Or why nobody cares to work on a design which actually
> matches what bluetooth specifications persue?

I actually have no real idea what your complaints are. The raw HCI
socket is different from an adapter in raw mode. I mentioned that
multiple times, but you don't seem to understand the difference. And
again, everybody who wants to do direct HCI programming is better off
writing their own stack. Leave the HCI handling to the kernel or hcid
and concentrate on real applications.

> Much worse is what happens if you create a connection. Until you get
> the connection complete event, everything is fine. But then, the
> kernel will issue several commands, ignoring any commands of yours
> until it's done. Among those is HCI_Write_Link_Policy_Settings. At
> this point it seems to be impossible to achieve for instance a role
> switch. Also, the kernel has no way to know what my program is trying
> to do, and thus can not know which is the link policy I need.
> 
> You see, everybody doing things like you and me (and I've seen more
> than just a few more out there) is just out of luck. The best would be
> somebody starting to fork the full development of Bluetooth support in
> Linux, but this time with a well thought design based on a thorough
> understanding of bluetooth and it's protocols.

Be my guest and start the fork. When you think you understand
everything, I will show you bits and pieces you haven't thought about.
At some point you will realize that various parts of the Bluetooth
specification have their own problems.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users