[Bluez-devel] hcid and bluetoothd

[Bluez-devel] hcid and bluetoothd

[Claudio Takahasi]

[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]

Hi Marcel,

You said in an old e-mail that hcid is your playground for D-Bus services. 
Probably, hcid D-Bus should be the starting point for bluetoothd.

I would like to align your ideas to avoid future reworks.

D-Bus provides 4 types of messages:
1. Method call
2. Method reply
3. Signals
4. Error
Currently, only signals are sent. The following signals are sent as result 
of the hci commands:
- InquiryStart
- InquiryResult
- InquiryComplete
- RemoteName
path: /org/bluez/DevAgent
interface: org.bluez.DevAgent

The topics that I want discuss are:
1. hcid signals
In my opinion it is not necessary send signals to notity inquiry 
start/complete. Only signals for news devices are enough. 
Another aspect is, inquiry result can contain repeated devices. This 
approach could cause D-Bus app client overhead(inconsistency), by other hand 
if periodic inquiry is active repeated signals must be sent because more 
than one client can be filtering these signals and they can start at 
different time. :)

2. hcid and bluetoothd object path
What is the object path that you want use?
I suggested in an old email use a hierarchical paths. bluetoothd can be the 
main object path provided at /org/bluez/bluetoothd, hci D-Bus services could 
be provided at /org/bluez/bluetoothd/hci

3. D-Bus services
hci D-BUS services is the next step, I am going to starting coding ASAP. 
Regarding inquiry requests, what kind of implementation do you prefer, send 
method reply message or send only signals(like the current)?
If you use signals, all D-Bus client capturing D-Bus hci signals are able to 
see the new devices found. Using a method reply only the peer (requestor) 
will receive. Using a method reply approach, we can implement device class 
filters and avoid repeated devices. We have the same problem for remote 
name, disconnect, authentication/security, info, role switch and display 
connections.

4. bluetoothd
There are shared codes like(pand/bnep.c, pand/sdp.c, hidd/sdp.c, ...) that 
we need be aware.
It is NOT clear for me how hcid and bluetoothd should work. hcid must be 
running all the time, but the hci D-Bus service will be running only if the 
system has a D-Bus system daemon running. Therefore, who should register the 
hci object path? IMHO, bluetoothd should centralize all D-Bus services. It 
will not be easy separate the "normal" code from the "D-Bus code". Maybe 
your "new interface" that your are defining can solve this problem.

5. new interface
You said that a new interface for kernel and the userspace communication is 
being defined. What is the current status?


Regards,
Claudio.

[-- Attachment #2: Type: text/html, Size: 2853 bytes --]

Re: [Bluez-devel] hcid and bluetoothd

[Marcel Holtmann]

Hi Claudio,

> You said in an old e-mail that hcid is your playground for D-Bus
> services. Probably, hcid D-Bus should be the starting point for
> bluetoothd.

since it is there and used, I think it is a good idea. At the moment it
is optional and so we can test it. At some point I will make bluez-utils
depend on D-Bus.

> I would like to align your ideas to avoid future reworks.
> 
> D-Bus provides 4 types of messages:
> 1. Method call
> 2. Method reply
> 3. Signals
> 4. Error
> Currently, only signals are sent. The following signals are sent as
> result of the hci commands:
> - InquiryStart
> - InquiryResult
> - InquiryComplete
> - RemoteName
> path: /org/bluez/DevAgent
> interface: org.bluez.DevAgent
> 
> The topics that I want discuss are:
> 1. hcid signals
> In my opinion it is not necessary send signals to notity inquiry
> start/complete. Only signals for news devices are enough. 

The idea behind also sending the InquiryStart and InquiryComplete events
is that applications can show some graphical indications that the local
device is now scanning for new devices in range. Since people can still
call "hcitool scan" it is need for applications to know when someone
else starts an inquiry.

> Another aspect is, inquiry result can contain repeated devices. This
> approach could cause D-Bus app client overhead(inconsistency), by
> other hand if periodic inquiry is active repeated signals must be sent
> because more than one client can be filtering these signals and they
> can start at different time. :)

And the RSSI values may changes in the repeated reponses. The clients
must do the filtering. There is no other way.

> 2. hcid and bluetoothd object path
> What is the object path that you want use?
> I suggested in an old email use a hierarchical paths. bluetoothd can
> be the main object path provided at /org/bluez/bluetoothd, hci D-Bus
> services could be provided at /org/bluez/bluetoothd/hci

The general idea is to abstract from any daemon names or Bluetooth
specification details. This makes it possible to reuse this interface
with FreeBSD in the future.

> 3. D-Bus services
> hci D-BUS services is the next step, I am going to starting coding
> ASAP. Regarding inquiry requests, what kind of implementation do you
> prefer, send method reply message or send only signals(like the
> current)?

We can do both, but I think signals should be preferred. This allows
graphical applications to dynamically update their lists.

> If you use signals, all D-Bus client capturing D-Bus hci signals are
> able to see the new devices found. Using a method reply only the peer
> (requestor) will receive. Using a method reply approach, we can
> implement device class filters and avoid repeated devices. We have the
> same problem for remote name, disconnect, authentication/security,
> info, role switch and display connections.

We should keep an eye on security, but the idea is to send stuff to
everybody that is interested in it.

> 4. bluetoothd
> There are shared codes like(pand/bnep.c, pand/sdp.c, hidd/sdp.c, ...)
> that we need be aware.
> It is NOT clear for me how hcid and bluetoothd should work. hcid must
> be running all the time, but the hci D-Bus service will be running
> only if the system has a D-Bus system daemon running. Therefore, who
> should register the hci object path? IMHO, bluetoothd should
> centralize all D-Bus services. It will not be easy separate the
> "normal" code from the "D-Bus code". Maybe your "new interface" that
> your are defining can solve this problem.

Once bluetoothd is in place hcid would no longer be needed.

> 5. new interface
> You said that a new interface for kernel and the userspace
> communication is being defined. What is the current status?

I am working on it.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcid and bluetoothd

[Claudio Takahasi]

[-- Attachment #1: Type: text/plain, Size: 6149 bytes --]

[Claudio Takahasi]
Hi Marcel,

On 9/15/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> 
> Hi Claudio,
> 
> > You said in an old e-mail that hcid is your playground for D-Bus
> > services. Probably, hcid D-Bus should be the starting point for
> > bluetoothd.
> 
> since it is there and used, I think it is a good idea. At the moment it
> is optional and so we can test it. At some point I will make bluez-utils
> depend on D-Bus.
> 
> > I would like to align your ideas to avoid future reworks.
> >
> > D-Bus provides 4 types of messages:
> > 1. Method call
> > 2. Method reply
> > 3. Signals
> > 4. Error
> > Currently, only signals are sent. The following signals are sent as
> > result of the hci commands:
> > - InquiryStart
> > - InquiryResult
> > - InquiryComplete
> > - RemoteName
> > path: /org/bluez/DevAgent
> > interface: org.bluez.DevAgent
> >
> > The topics that I want discuss are:
> > 1. hcid signals
> > In my opinion it is not necessary send signals to notity inquiry
> > start/complete. Only signals for news devices are enough.
> 
> The idea behind also sending the InquiryStart and InquiryComplete events
> is that applications can show some graphical indications that the local
> device is now scanning for new devices in range. Since people can still
> call "hcitool scan" it is need for applications to know when someone
> else starts an inquiry.

> Another aspect is, inquiry result can contain repeated devices. This

> > approach could cause D-Bus app client overhead(inconsistency), by
> > other hand if periodic inquiry is active repeated signals must be sent
> > because more than one client can be filtering these signals and they
> > can start at different time. :)
> 
> And the RSSI values may changes in the repeated reponses. The clients
> must do the filtering. There is no other way.


[Claudio Takahasi]
Remember that we need cover normal inquiry and periodic inquiry. For 
periodic inquiry
I agree with this approach of send signals every time. We can implement a 
cache 
to make the inquiry fast/powerful. Two or more clients can request inquiry 
at same 
time, this is a normal scenario, but it can happen. For normal inquiry, we 
can't
use hci_inquiry because it a blocking operation. The inquiry must be 
integrated
in the main loop of the bluetoothd, using a HCI raw socket or the new 
interface that 
your are defining.

> 2. hcid and bluetoothd object path
> > What is the object path that you want use?
> > I suggested in an old email use a hierarchical paths. bluetoothd can
> > be the main object path provided at /org/bluez/bluetoothd, hci D-Bus
> > services could be provided at /org/bluez/bluetoothd/hci
> 
> The general idea is to abstract from any daemon names or Bluetooth
> specification details. This makes it possible to reuse this interface
> with FreeBSD in the future.

[Claudio Takahasi]
I suggested previously use the bus name "org.bluez.bluetoothd", but do you 
think 
relevant participate on freedesktop project?

The bus name could be "org.freedesktop.Bluez"

I don't know what are the advantages and which rules we need respect.

> 3. D-Bus services
> > hci D-BUS services is the next step, I am going to starting coding
> > ASAP. Regarding inquiry requests, what kind of implementation do you
> > prefer, send method reply message or send only signals(like the
> > current)?
> 
> We can do both, but I think signals should be preferred. This allows
> graphical applications to dynamically update their lists.


[Claudio Takahasi] 
I agree. We need define exactly which signals are necessary. I am going 
to update the specification document that I am writing and I will send you 
soon.

> If you use signals, all D-Bus client capturing D-Bus hci signals are
> > able to see the new devices found. Using a method reply only the peer
> > (requestor) will receive. Using a method reply approach, we can
> > implement device class filters and avoid repeated devices. We have the
> > same problem for remote name, disconnect, authentication/security,
> > info, role switch and display connections.
> 
> We should keep an eye on security, but the idea is to send stuff to
> everybody that is interested in it.
> 
> > 4. bluetoothd
> > There are shared codes like(pand/bnep.c, pand/sdp.c, hidd/sdp.c, ...)
> > that we need be aware.
> > It is NOT clear for me how hcid and bluetoothd should work. hcid must
> > be running all the time, but the hci D-Bus service will be running
> > only if the system has a D-Bus system daemon running. Therefore, who
> > should register the hci object path? IMHO, bluetoothd should
> > centralize all D-Bus services. It will not be easy separate the
> > "normal" code from the "D-Bus code". Maybe your "new interface" that
> > your are defining can solve this problem.
> 
> Once bluetoothd is in place hcid would no longer be needed.


[Claudio Takahasi] 
hcid already contains the structure(main loop) required to register 
D-Bus services, it will be easy implement the D-Bus services.

Regarding sdpd, currently an application have to connect(sdp_connect) 
and stablish a session to register/update a service. 
sdp D-Bus service shall be provided in the future, how do you 
think it should work in this new scenario?

> 5. new interface
> > You said that a new interface for kernel and the userspace
> > communication is being defined. What is the current status?
> 
> I am working on it.


[Claudio Takahasi] 
Where is the CVS branch? If possible, send me the address.

Regards
> 
> Marcel
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>

[-- Attachment #2: Type: text/html, Size: 7942 bytes --]

Re: [Bluez-devel] hcid and bluetoothd

[Marcel Holtmann]

Hi Claudio,

> Remember that we need cover  normal inquiry and periodic inquiry. For
> periodic inquiry
> I agree with this approach of send signals every time. We can
> implement a cache 
> to make the inquiry fast/powerful. Two or more clients can request
> inquiry at same 
> time, this is a normal scenario, but it can happen. For normal
> inquiry, we can't
> use hci_inquiry because it a blocking operation. The inquiry must be
> integrated
> in the main loop of the bluetoothd, using a HCI raw socket or the new
> interface that 
> your are defining.

the kernel already has an inquiry cache. We can simply deliver that
cache at the moment.

I am not going to duplicate the inquiry stuff inside bluetoothd. We will
do it in hcid for now, but for bluetoothd the kernel should do all the
work.

> I suggested  previously use the bus name "org.bluez.bluetoothd", but
> do you think 
> relevant participate on freedesktop project?
> 
> The bus name could be "org.freedesktop.Bluez"
> 
> I don't know what are the advantages and which rules we need respect.

For now we will use "org.bluez" as base and I think about moving over to
"org.bluetooth" and propose it as an additional standard. However that
is not so important at the moment.

I like to use names that don't have any daemon names in it. This means
that something like "org.bluez.bluetoothd" is bad if FreeBSD wants to
provide a compat interface, but they don't call their daemon bluetoothd.
So what I like to see is something like "org.bluetooth.device" and so
on. Make it more logical. We don't even have to use the Bluetooth
terminology. This includes HCI command names. In general I like to have
an "discovery" procedure. This is doing an inquiry, a name resolve and
the SDP service stuff. In case of EIR the inquiry response may deliver
already enough information, because it can include a short name and a
service UUID list.

> I agree. We need define exactly which signals are necessary. I am
> going 
> to update the specification document that I am writing and I will send
> you soon.

My idea is to have multiple Bluetooth clients running at the same time
and if one starts a new inquiry the others also got informed of these
results. What they do with this results is their problem. I can draw a
picture if needed, but I think my ideas behind it are clear.

> hcid already contains the structure(main loop) required to register 
> D-Bus services, it will be easy implement the D-Bus services.

Since I dropped D-Bus 0.23 support now, I am happy to accept any
extensions to hcid.

> Regarding sdpd, currently an  application have to connect
> (sdp_connect) 
> and stablish a session to register/update a service. 
> sdp D-Bus service shall  be provided in the future, how do you 
> think it should work in this new scenario?

The SDP stuff is blocking at the moment and that is bad. My idea is to
rewrite the SDP support and include it in bluetoothd. This means that it
will be capable of caching SDP information and D-Bus clients can ask for
service information quite easy. This is also important with the extended
inquiry support, because the UUID list can be provided via an inquiry
response. And of course bluetoothd should add the UUID of all registered
services to the extended inquiry data when someone registers a new
record via D-Bus.

> Where is the CVS branch? If possible, send me the address.

It will be in the GIT tree, when I have some spare time to clean it.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel