All of lore.kernel.org
 help / color / mirror / Atom feed
* [Bluez-devel] New SDP client library
@ 2003-08-25 11:29 Marcel Holtmann
  2003-10-09  0:35 ` Max Krasnyansky
  0 siblings, 1 reply; 5+ messages in thread
From: Marcel Holtmann @ 2003-08-25 11:29 UTC (permalink / raw)
  To: BlueZ Mailing List

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

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


[-- Attachment #2: sdp.h --]
[-- Type: text/x-c-header, Size: 4873 bytes --]

/*
 *
 *  Bluetooth library for the offical Linux Bluetooth protocol stack
 *
 *  Copyright (C) 2002-2003  Marcel Holtmann <marcel@holtmann.org>
 *
 *
 *  This library is free software; you can redistribute it and/or
 *  modify it under the terms of the GNU Lesser General Public
 *  License as published by the Free Software Foundation; either
 *  version 2.1 of the License, or (at your option) any later version.
 *
 *  This library is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 *  Lesser General Public License for more details.
 *
 *  You should have received a copy of the GNU Lesser General Public
 *  License along with this library; if not, write to the Free Software
 *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 *
 *
 *  $Id: sdp.h,v 1.3 2003/07/25 21:45:52 holtmann Exp $
 */

#ifndef __SDP_H
#define __SDP_H

#ifdef __cplusplus
extern "C" {
#endif

#define SDP_SDP						0x0001
#define SDP_UDP						0x0002
#define SDP_RFCOMM					0x0003
#define SDP_TCP						0x0004
#define SDP_TCS_BIN					0x0005
#define SDP_TCS_AT					0x0006
#define SDP_OBEX					0x0008
#define SDP_IP						0x0009
#define SDP_FTP						0x000a
#define SDP_HTTP					0x000c
#define SDP_WSP						0x000e
#define SDP_BNEP					0x000f
#define SDP_UPNP					0x0010
#define SDP_HIDP					0x0011
#define SDP_HARDCOPY_CONTROL_CHANNEL			0x0012
#define SDP_HARDCOPY_DATA_CHANNEL			0x0014
#define SDP_HARDCOPY_NOTIFICATION			0x0016
#define SDP_AVCTP					0x0017
#define SDP_AVDTP					0x0019
#define SDP_CMTP					0x001b
#define SDP_UDI_C_PLANE					0x001d
#define SDP_L2CAP					0x0100

#define SDP_SERVICE_DISCOVERY_SERVER_SERVICE_CLASS_ID	0x1000
#define SDP_BROWSE_GROUP_DESCRIPTOR_SERVICE_CLASS_ID	0x1001
#define SDP_PUBLIC_BROWSE_GROUP				0x1002

#define SDP_SERIAL_PORT					0x1101
#define SDP_LAN_ACCESS_USING_PPP			0x1102
#define SDP_DIALUP_NETWORKING				0x1103
#define SDP_IRMC_SYNC					0x1104
#define SDP_OBEX_OBJECT_PUSH				0x1105
#define SDP_OBEX_FILE_TRANSFER				0x1106
#define SDP_IRMC_SYNC_COMMAND				0x1107
#define SDP_HEADSET					0x1108
#define SDP_CORDLESS_TELEPHONY				0x1109
#define SDP_AUDIO_SOURCE				0x110a
#define SDP_AUDIO_SINK					0x110b
#define SDP_AV_REMOTE_CONTROL_TARGET			0x110c
#define SDP_ADVANCED_AUDIO_DISTRIBUTION			0x110d
#define SDP_AV_REMOTE_CONTROL				0x110e
#define SDP_VIDEO_CONFERENCING				0x110f
#define SDP_INTERCOM					0x1110
#define SDP_FAX						0x1111
#define SDP_HEADSET_AUDIO_GATEWAY			0x1112
#define SDP_WAP						0x1113
#define SDP_WAP_CLIENT					0x1114
#define SDP_PANU					0x1115
#define SDP_NAP						0x1116
#define SDP_GN						0x1117
#define SDP_DIRECT_PRINTING				0x1118
#define SDP_REFERENCE_PRINTING				0x1119
#define SDP_IMAGING					0x111a
#define SDP_IMAGING_RESPONDER				0x111b
#define SDP_IMAGING_AUTOMATIC_ARCHIVE			0x111c
#define SDP_IMAGING_REFERENCED_OBJECTS			0x111d
#define SDP_HANDSFREE					0x111e
#define SDP_HANDSFREE_AUDIO_GATEWAY			0x111f
#define SDP_DIRECT_PRINTING_REFERENCE_OBJECTS_SERVICE	0x1120
#define SDP_REFLECTED_UI				0x1121
#define SDP_BASIC_PRINTING				0x1122
#define SDP_PRINTING_STATUS				0x1123
#define SDP_HUMAN_INTERFACE_DEVICE_SERVICE		0x1124
#define SDP_HARDCOPY_CABLE_REPLACEMENT			0x1125
#define SDP_HCR_PRINT					0x1126
#define SDP_HCR_SCAN					0x1127
#define SDP_COMMON_ISDN_ACCESS				0x1128
#define SDP_VIDEO_CONFERENCING_GW			0x1129
#define SDP_UDI_MT					0x112a
#define SDP_UDI_TA					0x112b
#define SDP_AUDIO_VIDEO					0x112c
#define SDP_SIM_ACCESS					0x112d

#define SDP_PNP_INFORMATION				0x1200
#define SDP_GENERIC_NETWORKING				0x1201
#define SDP_GENERIC_FILE_TRANSFER			0x1202
#define SDP_GENERIC_AUDIO				0x1203
#define SDP_GENERIC_TELEPHONY				0x1204
#define SDP_UPNP_SERVICE				0x1205
#define SDP_UPNP_IP_SERVICE				0x1206

#define SDP_ESDP_UPNP_IP_PAN				0x1300
#define SDP_ESDP_UPNP_IP_LAP				0x1301
#define SDP_ESDP_UPNP_L2CAP				0x1301

typedef uint16_t uuid16_t;

char *sdp_uuid16tostr(uuid16_t uuid);

typedef struct {
	uint32_t handle;
	uuid16_t class;
	struct {
		uuid16_t uuid;
		uint16_t psm;
		uint8_t channel;
	} proto[2];
	char name[248];
} sdp_record_t;

typedef struct {
	int sock;
	unsigned long flags;
	uint8_t pid;
	uint16_t tid;
} sdp_t;

sdp_t *sdp_connect(const bdaddr_t *src, const bdaddr_t *dst, unsigned long flags);
int sdp_close(sdp_t *sdp);

int sdp_service_search(sdp_t *sdp, uuid16_t uuid, uint32_t *handles, uint16_t count);
int sdp_service_attribute(sdp_t *sdp, uint32_t handle, sdp_record_t *record);
int sdp_service_search_attribute(sdp_t *sdp, uuid16_t uuid, sdp_record_t *records, uint16_t count);

#ifdef __cplusplus
}
#endif

#endif /* __SDP_H */

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-devel] New SDP client library
  2003-08-25 11:29 [Bluez-devel] New SDP client library Marcel Holtmann
@ 2003-10-09  0:35 ` Max Krasnyansky
  2003-10-09 16:06   ` Marcel Holtmann
  0 siblings, 1 reply; 5+ messages in thread
From: Max Krasnyansky @ 2003-10-09  0:35 UTC (permalink / raw)
  To: Marcel Holtmann, BlueZ Mailing List

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-devel] New SDP client library
  2003-10-09  0:35 ` Max Krasnyansky
@ 2003-10-09 16:06   ` Marcel Holtmann
  2003-10-09 17:31     ` Max Krasnyansky
  0 siblings, 1 reply; 5+ messages in thread
From: Marcel Holtmann @ 2003-10-09 16:06 UTC (permalink / raw)
  To: Max Krasnyansky; +Cc: BlueZ Mailing List

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-devel] New SDP client library
  2003-10-09 16:06   ` Marcel Holtmann
@ 2003-10-09 17:31     ` Max Krasnyansky
  2003-10-09 18:02       ` Marcel Holtmann
  0 siblings, 1 reply; 5+ messages in thread
From: Max Krasnyansky @ 2003-10-09 17:31 UTC (permalink / raw)
  To: Marcel Holtmann; +Cc: BlueZ Mailing List

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-devel] New SDP client library
  2003-10-09 17:31     ` Max Krasnyansky
@ 2003-10-09 18:02       ` Marcel Holtmann
  0 siblings, 0 replies; 5+ messages in thread
From: Marcel Holtmann @ 2003-10-09 18:02 UTC (permalink / raw)
  To: Max Krasnyansky; +Cc: BlueZ Mailing List

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-10-09 18:02 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-08-25 11:29 [Bluez-devel] New SDP client library Marcel Holtmann
2003-10-09  0:35 ` Max Krasnyansky
2003-10-09 16:06   ` Marcel Holtmann
2003-10-09 17:31     ` Max Krasnyansky
2003-10-09 18:02       ` Marcel Holtmann

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.