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

["siddhant tewari" <siddhant.tewari@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 6116 bytes --]

hi Cris,

    With linux being one of the major players in embedded domain and bluez
being an official protocol of linux there is definitely a great need for
multi connection support. You have suggested that somebody with a thorough
understanding of bluetooth and its protocol should start to fork the full
development of bluetooth support in linux , but that somebody cannot be at
least me at this instance as i am just a starter and it took some effort
from my side to even get the idea of what u wrote ... i think it should be
someone like you who has such a clear picture of the problem or to be more
precise really understands the problem well , who can initiate such
development... all i can say is that i am ready to work if somebody  can
guide me ....

Please tell me what are the other options parallel to bluez and is it really
advisable to  use them .

I am stuck at this problem and i dont like leaving it as such.

regards
siddhant

On 1/2
 /07, Cris <ml133@netpole.com.br> wrote:
>
> On Tue, 2 Jan 2007 15:59:19 +0530
> "siddhant tewari" <siddhant.tewari@gmail.com> wrote:
>
> > hi cris,
> >            I tried similar thing using OBEX push client and the thing
> that
> > happened is exactly what u apprehended ...
> >     ->  One thread waited for the other to get completed .... sad blues
> > behavior.....this is exactly what is creating trouble in my application
> ...
>
> 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.
>
> 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.
>
> 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?
>
> 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.
>
> -------------------------------------------------------------------------
> 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
>

[-- Attachment #1.2: Type: text/html, Size: 7024 bytes --]

[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users