The process of searching for services involves two steps - detecting all nearby devices with a device inquiry, and connecting to each of those devices in turn to search for the desired service. Despite Bluetooth's piconet abilities, the early versions don't support multicasting queries, so this must be done the slow way. Since detecting nearby devices was covered in Section 4.1 , only the second step is described here.
Searching a specific device for a service also involves two steps. The first part, shown in Example 4-7 , requires connecting to the device and sending the search request. The second part, shown in in Example 4-8 , involves parsing and interpreting the search results.
Example 4-7. Step one of searching a device for a service with UUID 0xABCD
#include #include #include int main(int argc, char **argv) < uint8_t svc_uuid_int[] = < 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xab, 0xcd >; uuid_t svc_uuid; int err; bdaddr_t target; sdp_list_t *response_list = NULL, *search_list, *attrid_list; sdp_session_t *session = 0; str2ba( "01:23:45:67:89:AB", &target ); // connect to the SDP server running on the remote machine session = sdp_connect( BDADDR_ANY, &target, SDP_RETRY_IF_BUSY ); // specify the UUID of the application we're searching for sdp_uuid128_create( &svc_uuid, &svc_uuid_int ); search_list = sdp_list_append( NULL, &svc_uuid ); // specify that we want a list of all the matching applications' attributes uint32_t range = 0x0000ffff; attrid_list = sdp_list_append( NULL, &range ); // get a list of service records that have UUID 0xabcd err = sdp_service_search_attr_req( session, search_list, \ SDP_ATTR_REQ_RANGE, attrid_list, &response_list); . .
The uuid_t data type is used to represent the 128-bit UUID that identifies the desired service. To obtain a valid uuid_t , create an array of 16 8-bit integers and use the sdp_uuid128_create function, which is similar to the str2ba function for converting strings to bdaddr_t types. sdp_connect synchronously connects to the SDP server running on the target device. sdp_service_search_attr_req searches the connected device for the desired service and requests a list of attributes specified by attrid_list . It's easiest to use the magic number 0x0000ffff to request a list of all the attributes describing the service, although it is possible, for example, to request only the name of a matching service and not its protocol information.
Continuing our example, we now get to the tricky part - parsing and interpreting the results of a search. Unfortunately, there isn't an easy way to do this. Taking the result of our search above, Example 4-8 shows how to extract the RFCOMM channel of a matching result.
Example 4-8. parsing and interpreting an SDP search result
sdp_list_t *r = response_list; // go through each of the service records for (; r; r = r->next ) < sdp_record_t *rec = (sdp_record_t*) r->data; sdp_list_t *proto_list; // get a list of the protocol sequences if( sdp_get_access_protos( rec, &proto_list ) == 0 ) < sdp_list_t *p = proto_list; // go through each protocol sequence for( ; p ; p = p->next ) < sdp_list_t *pds = (sdp_list_t*)p->data; // go through each protocol list of the protocol sequence for( ; pds ; pds = pds->next ) < // check the protocol attributes sdp_data_t *d = (sdp_data_t*)pds->data; int proto = 0; for( ; d; d = d->next ) < switch( d->dtd ) < case SDP_UUID16: case SDP_UUID32: case SDP_UUID128: proto = sdp_uuid_to_proto( &d->val.uuid ); break; case SDP_UINT8: if( proto == RFCOMM_UUID ) < printf("rfcomm channel: %d\n",d->val.int8); > break; > > > sdp_list_free( (sdp_list_t*)p->data, 0 ); > sdp_list_free( proto_list, 0 ); > printf("found service record 0x%x\n", rec->handle); sdp_record_free( rec ); > sdp_close(session); >
Getting the protocol information requires digging deep into the search results. Since it's possible for multiple application services to match a single search request, a list of service records is used to describe each matching service. For each service that's running, it's (theoretically, but not usually done in practice) possible to have different ways of connecting to the service. So each service record has a list of protocol sequences that each describe a different way to connect. Furthermore, since protocols can be built on top of other protocols (e.g. RFCOMM uses L2CAP as a transport), each protocol sequence has a list of protocols that the application uses, only one of which actually matters. Finally, each protocol entry will have a list of attributes , like the protocol type and the port number it's running on. Thus, obtaining the port number for an application that uses RFCOMM requires finding the port number protocol attribute in the RFCOMM protocol entry.
In this example, several new data structures have been introduced that we haven't seen before.
typedef struct _sdp_list_t < struct _sdp_list_t *next; void *data; >sdp_list_t; typedef void(*sdp_free_func_t)(void *) sdp_list_t *sdp_list_append(sdp_list_t *list, void *d); sdp_list_t *sdp_list_free(sdp_list_t *list, sdp_list_func_t f);
Since C does not have a built in linked-list data structure, and SDP search criteria and search results are essentially nothing but lists of data, the BlueZ developers wrote their own linked list data structure and called it sdp_list_t . For now, it suffices to know that appending to a NULL list creates a new linked list, and that a list must be deallocated with sdp_list_free when it is no longer needed.
The sdp_record_t data structure represents a single service record being advertised by another device. Its inner details aren't important, as there are a number of helper functions available to get information in and out of it. In this example, sdp_get_access_protos is used to extract a list of the protocols for the service record.
Finally, there is the sdp_data_t structure, which is ultimately used to store each element of information in a service record. At a high level, it is a node of a linked list that carries a piece of data (the val field). As a variable type data structure, it can be used in different ways, depending on the context. For now, it's sufficient to know that each protocol stack in the list of protocol sequences is represented as a singly linked list of sdp_data_t structures, and extracting the protocol and port information requires iterating through this list until the proper elements are found. The type of a sdp_data_t is specified by the dtd field, which is what we use to search the list.
Every Bluetooth device typically runs an SDP server that answers queries from other Bluetooth devices. In BlueZ, the implementation of the SDP server is called sdpd , and is usually started by the system boot scripts. sdpd handles all incoming SDP search requests. Applications that need to advertise a Bluetooth service must use inter-process communication (IPC) methods to tell sdpd what to advertise. Currently, this is done with the named pipe /var/run/sdp . BlueZ provides convenience functions written to make this process a little easier.
Registering a service with sdpd involves describing the service to advertise, connected to sdpd , instructing sdpd on what to advertise, and then disconnecting.
Describing a service is essentially building the service record that was parsed in the previous examples. This involves creating several lists and populating them with data attributes. Example 4-9 shows how to describe a service application with UUID 0xABCD that runs on RFCOMM channel 11, is named ``Roto-Rooter Data Router", provided by ``Roto-Rooter", and has the description ``An experimental plumbing router"
Example 4-9. Describing a service
#include #include #include sdp_session_t *register_service() < uint32_t service_uuid_int[] = < 0, 0, 0, 0xABCD >; uint8_t rfcomm_channel = 11; const char *service_name = "Roto-Rooter Data Router"; const char *service_dsc = "An experimental plumbing router"; const char *service_prov = "Roto-Rooter"; uuid_t root_uuid, l2cap_uuid, rfcomm_uuid, svc_uuid; sdp_list_t *l2cap_list = 0, *rfcomm_list = 0, *root_list = 0, *proto_list = 0, *access_proto_list = 0; sdp_data_t *channel = 0, *psm = 0; sdp_record_t *record = sdp_record_alloc(); // set the general service ID sdp_uuid128_create( &svc_uuid, &service_uuid_int ); sdp_set_service_id( record, svc_uuid ); // make the service record publicly browsable sdp_uuid16_create(&root_uuid, PUBLIC_BROWSE_GROUP); root_list = sdp_list_append(0, &root_uuid); sdp_set_browse_groups( record, root_list ); // set l2cap information sdp_uuid16_create(&l2cap_uuid, L2CAP_UUID); l2cap_list = sdp_list_append( 0, &l2cap_uuid ); proto_list = sdp_list_append( 0, l2cap_list ); // set rfcomm information sdp_uuid16_create(&rfcomm_uuid, RFCOMM_UUID); channel = sdp_data_alloc(SDP_UINT8, &rfcomm_channel); rfcomm_list = sdp_list_append( 0, &rfcomm_uuid ); sdp_list_append( rfcomm_list, channel ); sdp_list_append( proto_list, rfcomm_list ); // attach protocol information to service record access_proto_list = sdp_list_append( 0, proto_list ); sdp_set_access_protos( record, access_proto_list ); // set the name, provider, and description sdp_set_info_attr(record, service_name, service_prov, service_dsc); . .
Building the description is quite straightforward, and consists of taking those five fields and packing them into data structures. Most of the work is just putting lists together. Once the service record is complete, the application connects to the local SDP server and registers a new service, taking care afterwards to free the data structures allocated earlier.
. . int err = 0; sdp_session_t *session = 0; // connect to the local SDP server, register the service record, and // disconnect session = sdp_connect( BDADDR_ANY, BDADDR_LOCAL, SDP_RETRY_IF_BUSY ); err = sdp_record_register(session, record, 0); // cleanup sdp_data_free( channel ); sdp_list_free( l2cap_list, 0 ); sdp_list_free( rfcomm_list, 0 ); sdp_list_free( root_list, 0 ); sdp_list_free( access_proto_list, 0 ); return session; >
The special argument BDADDR_LOCAL causes sdp_connect to connect to the local SDP server (via the named pipe /var/run/sdp ) instead of a remote device. Once an active session is established with the local SDP server, sdp_record_register advertises a service record. The service will be advertised for as long as the session with the SDP server is kept open. As soon as the SDP server detects that the socket connection is closed, it will stop advertising the service. sdp_close terminates a session with the SDP server.
sdp_session_t *sdp_connect( const bdaddr_t *src, const bdaddr_t *dst, uint32_t flags ); int sdp_close( sdp_session_t *session ); int sdp_record_register(sdp_session_t *sess, sdp_record_t *rec, uint8_t flags);
| Prev | Home | Next |
| L2CAP sockets | Up | Advanced BlueZ programming |