Hi Folks,
in the last two months I have done much work with the current SDP
implementation. The library is full featured and works fine for me in
all situations, but the programming interface is a mess. It is not easy
to get the service name or the number of the RFCOMM channel. You have to
play with internal SDP lists, pointer of pointer stuff and static
assigned UUID's. Since I already have rewritten most of the HCI part
from scratch for the new Bluetooth library, so I decided to also build a
new client SDP libary from scratch. I took me one day to get a first
draft of a working version and I am positiv astonished how easy it can
be.
While coding the new library I came to the conclusion that we need two
interfaces to SDP. A simple one for basic tasks like getting service
name and needed protocol information and a second full featured API
which can do everything according to spec. For the simple API I made
some assumptions to achieve a simple interface:
1) The simple API can only deal with UUID16
2) A request can only contain one UUID
3) It always requests the full range of attributes
4) It returns only a predefined number of attributes
5) No function return dynamic allocated memory/lists
Both interfaces share two common functions, which are needed for SDP
connection creation and clearing. These functions are also present in
the current library, but I named the datatype sdp_t instead of
sdp_session_t to keep it short:
sdp_t *sdp_connect(...);
int sdp_close(sdp_t *sdp);
The simple API only contains three additional functions which reflects
the three request PDU's of the SDP specification:
int sdp_service_search(sdp_t *sdp, ...);
int sdp_service_attribute(sdp_t *sdp, ...);
int sdp_service_search_attribute(sdp_t *sdp, ...);
All data exchange is done through the sdp_record_t datatype, a uint32_t
for the record handle and/or a UUID16 for the service class. I attached
the complete sdp.h file with all definitions of the new simple interface
to this email. And here is a little client programing example, which
gets all serial port profile records:
sdp_t *sdp;
sdp_record_t records[6];
int i, num
sdp = sdp_connect(BDADDR_ANY, bdaddr, 0);
num = sdp_service_search_attribute(sdp, SDP_SERIAL_PORT, records, 6);
for (i = 0; i < num; i++)
printf("Service: %s\n", records[i].name);
sdp_close(sdp);
The simple interface will have of course a lot of limitations, but these
can all be eliminated by using the full interface if needed. I tested
the new version with all my devices on my desktop and it works flawless.
The internal code of the library and also the full featured interface
depends only on the datatype sdp_data_t. This struct can represent the
complete SDP data definitions. No additional lists or other helper
structs are needed. It is easy to decode and encode this datatype to the
SDP binary representation and the full featured interface uses it also
for input of the UUID lists and the attribute ranges. At the moment this
part of the implementation contains only the code which is needed to
make the simple interface working.
I will now clean up the internal stuff a little bit and then place it
into the libs2 CVS instead of the "old" one. Comments?
Regards
Marcel
Hi Max,
> >> >Since I already have rewritten most of the HCI part
> >> >from scratch for the new Bluetooth library,
> >> Hmm, what do you mean by that ? As far as I can (in CVS) core functions
> >> like hci_open(), hci_send_request(), etc are the same.
> >
> >I started with an empty hci.c file and begin looking at the old library.
> >And of course most functions will be the same, because they are simple,
> >correct and worked fine for over two years now.
> You cannot claim that you rewrote the whole thing from the scratch if those
> functions are the same ;-).
I never said that I rewrote the whole thing ;) Why should I do this if
the code is good ;)
The mainly new part is that all HCI commands and events are now present
(I also have a patch for the Bluetooth 1.2 ones). Some of them need some
more attention, but in general we have now a full API for the HCI layer.
> >> >The simple interface will have of course a lot of limitations, but these
> >> >can all be eliminated by using the full interface if needed. I tested
> >> >the new version with all my devices on my desktop and it works flawless.
> >> Cool.
> >
> >Not so cool as I thought in the first place :( While working with the
> >new library and testing them on other profiles like BIP, HID and HCRP
> >for example, things are getting worse again. It is hard to see the
> >complete picture of SDP.
> >
> >> >I will now clean up the internal stuff a little bit and then place it
> >> >into the libs2 CVS instead of the "old" one. Comments?
> >> Looks good to me. We've been talking about simplifying SDP library
> >> for quite a while. And I completely support the idea.
> >
> >The current CVS misses some more macros I have already coded, but not
> >yet commited. They will make the work with SDP much easier. In the case
> >of BIP, HID and HCRP we really need good SDP support.
>
> Sounds like we should keep both (old and new) libraries for now.
I came to the same conclusion and I am working on it since last week.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 09:06 AM 10/9/2003, Marcel Holtmann wrote:
>> >Since I already have rewritten most of the HCI part
>> >from scratch for the new Bluetooth library,
>> Hmm, what do you mean by that ? As far as I can (in CVS) core functions
>> like hci_open(), hci_send_request(), etc are the same.
>
>I started with an empty hci.c file and begin looking at the old library.
>And of course most functions will be the same, because they are simple,
>correct and worked fine for over two years now.
You cannot claim that you rewrote the whole thing from the scratch if those
functions are the same ;-).
>> >The simple interface will have of course a lot of limitations, but these
>> >can all be eliminated by using the full interface if needed. I tested
>> >the new version with all my devices on my desktop and it works flawless.
>> Cool.
>
>Not so cool as I thought in the first place :( While working with the
>new library and testing them on other profiles like BIP, HID and HCRP
>for example, things are getting worse again. It is hard to see the
>complete picture of SDP.
>
>> >I will now clean up the internal stuff a little bit and then place it
>> >into the libs2 CVS instead of the "old" one. Comments?
>> Looks good to me. We've been talking about simplifying SDP library
>> for quite a while. And I completely support the idea.
>
>The current CVS misses some more macros I have already coded, but not
>yet commited. They will make the work with SDP much easier. In the case
>of BIP, HID and HCRP we really need good SDP support.
Sounds like we should keep both (old and new) libraries for now.
Max
Hi Max,
> >in the last two months I have done much work with the current SDP
> >implementation. The library is full featured and works fine for me in
> >all situations, but the programming interface is a mess. It is not easy
> >to get the service name or the number of the RFCOMM channel. You have to
> >play with internal SDP lists, pointer of pointer stuff and static
> >assigned UUID's. Since I already have rewritten most of the HCI part
> >from scratch for the new Bluetooth library,
> Hmm, what do you mean by that ? As far as I can (in CVS) core functions
> like hci_open(), hci_send_request(), etc are the same.
I started with an empty hci.c file and begin looking at the old library.
And of course most functions will be the same, because they are simple,
correct and worked fine for over two years now. The hci_types.h file
will be more amazing ;)
> >The simple interface will have of course a lot of limitations, but these
> >can all be eliminated by using the full interface if needed. I tested
> >the new version with all my devices on my desktop and it works flawless.
> Cool.
Not so cool as I thought in the first place :( While working with the
new library and testing them on other profiles like BIP, HID and HCRP
for example, things are getting worse again. It is hard to see the
complete picture of SDP.
> >I will now clean up the internal stuff a little bit and then place it
> >into the libs2 CVS instead of the "old" one. Comments?
> Looks good to me. We've been talking about simplifying SDP library
> for quite a while. And I completely support the idea.
The current CVS misses some more macros I have already coded, but not
yet commited. They will make the work with SDP much easier. In the case
of BIP, HID and HCRP we really need good SDP support.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 04:29 AM 8/25/2003, Marcel Holtmann wrote:
>Hi Folks,
>
>in the last two months I have done much work with the current SDP
>implementation. The library is full featured and works fine for me in
>all situations, but the programming interface is a mess. It is not easy
>to get the service name or the number of the RFCOMM channel. You have to
>play with internal SDP lists, pointer of pointer stuff and static
>assigned UUID's. Since I already have rewritten most of the HCI part
>from scratch for the new Bluetooth library,
Hmm, what do you mean by that ? As far as I can (in CVS) core functions
like hci_open(), hci_send_request(), etc are the same.
>The simple interface will have of course a lot of limitations, but these
>can all be eliminated by using the full interface if needed. I tested
>the new version with all my devices on my desktop and it works flawless.
Cool.
>I will now clean up the internal stuff a little bit and then place it
>into the libs2 CVS instead of the "old" one. Comments?
Looks good to me. We've been talking about simplifying SDP library
for quite a while. And I completely support the idea.
Thanks
Max