Symbian OS Communications (779884), страница 18
Текст из файла (страница 18)
Without the error control mechanisms ofL2CAP 1.2, more complex mechanisms are required to provide optimumtransport of AV data and RFCOMM data on the same link. The errorcontrol feature of L2CAP 1.2 provides a much improved way of assuringreliable data transfer alongside time-sensitive data on the same link.Without per-channel flow control, aggregate flow control at the layerbeneath L2CAP is necessary. This implies that some L2CAP channelsthat have data to transmit are not allowed to do so if there are anyother Bluetooth services using the ACL transport that are consuming dataslowly, and thus causing the whole link to be flowed off. This problem issolved by the use of per-channel flow control in L2CAP 1.2 as individualL2CAP channels can now perform flow control, rather than it being aproperty of the whole ACL link.5The SAR feature in L2CAP 1.2 allows the L2CAP multiplexers to providebetter latencies to services that require data to be sent within given timebounds. Without SAR, an L2CAP multiplexer is blocked all the time anservice’s data packet is being sent by the multiplexer.
So, an service thatsends low-latency, small packets will have its performance affected by anservice that is sending larger packets with no latency requirements sincethe large packets will make the multiplexer wait longer before sendingthe small packets. SAR allows the L2CAP entities to split applicationpackets (SDUs) into smaller packets (PDUs), and interleave PDUs fromdifferent SDUs. This allows the latency requirements of certain servicesto be satisfied in a more deterministic manner.4.1.6 Service DiscoveryService discovery in Bluetooth is performed using the service discovery protocol (SDP) – a rich protocol defined in the Core Bluetoothspecification that allows a Bluetooth device to find out about servicesthat are available on another Bluetooth device.5Remember that the ACL logical link exists between a pair of devices, so this only causesproblems if there are multiple services running between the devices.
In cases where theremote devices only offer a single service, this problem is far less likely to occur – however,problems can still persist if a service requires more than one L2CAP channel.BLUETOOTH TECHNOLOGY OVERVIEW75Any Bluetooth device that offers services has a service discoverydatabase (SDDB), in which a series of records are stored describing theservices that device offers. Services on the device register with the localSDDB, which is then queried by remote devices.Each service running on a Bluetooth device should advertise a recordin the SDDB. An SDP record is a set of attributes, where an attribute is apair consisting of an ID and arbitrary value.
A particularly important typein SDP is the universally unique identifier (UUID). UUIDs are used toidentify protocols, profiles, services and service classes in SDP; with theSDP specification making the bold claim that each UUID is guaranteedto be unique across all space and all time.Structure of the databaseThe structure of information in the SDDB can be considered in twoways – what we’ll call the ‘logical’ structure and what we’ll call the‘physical’ structure. The physical structure is basically a serialized versionof the data, like blocks on a disc, and is shown in Figure 4.5. This is howthe database is described by the Bluetooth specification. There is also alogical view of the data, like a filesystem view of a disc – this is shown inFigure 4.4. You will probably find it much easier to understand the logicalIdentified by service record handleattributeThis is a DESServiceRecordThis is anattribute uniqueto this serviceclassAttributes in this partin the record haveglobal attribute IDs<Attribute ID><AttributeValue>ProtocolDescriptorListProtocolDescriptor1ProtocolDescriptor2ProtocolDescriptorNL2CAPRFCOMM<protocol><PSM><serverchannel>ServiceClass<UUID1><Attribute ID><AttributeValue><UUID2><UUID N>Attributes in this part of the recordare scoped by the ServiceClassattributeFigure 4.4 A logical view of a service record in service discovery database76BLUETOOTHService recordAttribute-valueAttribute-valueAttribute-valueAttribute-valueAttribute-valueFigure 4.5 A physical view of a service record in the service discovery databaseview as it makes certain relationships more obvious.
Just bear in mindwhen using the APIs that the underlying representation uses the physicalview – each service record being represented by a list of attribute-valuepairs, rather than any form of hierarchical structure being imposed.In the physical view, the service record handle is just another attributevalue pair. In the logical view, it represents the handle to the entire servicerecord.Important note: a service that needs to register itself in the SDDB willneed a 128-bit UUID to use as a service class. This should be generatedonce, using a UUID generator, of which there are plenty available onthe internet, then hard coded into the application. After this has beendone, that UUID should always be used as that application’s serviceclass when registering in the SDDB.Since SDP has a lot of potentially confusing terminology – here’s aquick note on our usage.
When we say ‘attribute’ we’re referring to theID and the value. If we mean either the ID or the value we’ll say soexplicitly.Attribute IDAn attribute ID is a 16-bit identifier. There are two main groups ofattributes IDs – globally defined ones, and ones defined by specific service classes. Globally defined attribute IDs and their usage are definedin the SDP specification, and include the expected things such asServiceRecordHandle and ServiceClassIDList, but also ProtocolDescriptorList (used for describing the protocol stack required to connect toa service – for example OBEX-RFCOMM-L2CAP, along with parametersused by those protocols – for example RFCOMM server channel number,L2CAP PSM). There are various other global attribute IDs that can beused – some will be seen in the examples later in this chapter.
In orderBLUETOOTH TECHNOLOGY OVERVIEW77to leave space for more global identifiers to be added, identifiers in therange 0x0000 to 0x01FF are reserved by the Bluetooth SIG.All other attribute IDs are scoped by a service class – this means thatinterpreting them requires looking at the service class attribute first. Thegood news here is that since you’re likely to be using your own serviceclass (unless you’re implementing a standard profile) then you can defineany attribute ID in the range 0x0200 to 0xFFFF for your own purposes.Attribute values 6There are two main sorts of value – individual values and lists of values.The lists of values have two subtypes – lists and lists from which onealternative should be selected (these are called data element sequences(DES ) and data element alternates (DEA), respectively).So overall there are nine types of value:• Unsigned integers• Signed, two-complement integers• UUIDs• Text strings• Booleans• Data element sequences (i.e., lists where all items are relevant)• Data element alternates (i.e., a list from which one alternate has to bechosen)• URLs• Nil (a NULL type).Just to make life harder, lists can themselves contain lists, and usuallydo! With the Symbian OS APIs, which work very much like a SAX-styleXML parser, this can make parsing some lists quite tricky as you need tomaintain some state yourself indicating which list you’re in.Searching for servicesNow that we’ve covered the basic structure of the database and the typesit contains, let’s look at how we query it.
Queries are performed usingthe service discovery protocol (SDP). In terms of protocol layering, it runsdirectly over L2CAP. It is a request–response protocol that allows accessService class(implicit scoping)Attribute IDAttribute valueFigure 4.6 Interpretation of non-global attribute Ids6Actually, attribute IDs are themselves values of a specific type (16-bit unsigned integers)but we’ll leave that confusing detail aside.78BLUETOOTHto a remote SDDB.
The requests, each of which has a response, are asfollows:• Service search – to discover if a specified UUID, or set of UUIDs,exists in any attributes of a service record that is available on a remotedevice.• Service attribute – to discover values of specified attributes belongingto a particular service record that is available on a remote device.• Service search-attribute – a combination of the above in a singlequery.Oddly for a protocol allowing queries of a (possibly large) remotedatabase, there is no ‘abort’ command. Therefore the only way to stop anongoing request on a remote SDP server is to disconnect the underlyingL2CAP connection.Because SDP responses may contain potentially large amounts of data,a mechanism exists for SDP servers to fragment responses into multipleL2CAP packets.
Oddly no equivalent mechanism exists for fragmentingSDP requests.The oddities of SDP enumerated above (fragmentation, packet typesand missing abort) are hidden from applications by Symbian OS. However, due to the complex syntax and structure of SDP attribute values,and the need for applications to be able to access all the possible attributevalues that might be returned, the Symbian OS SDP APIs remain complex.The SDP protocol follows a request/response pattern. Typically theprocedure to detect the presence of a service on a remote device is asfollows:1.The SDP client sends a Service Search Request, with a list of UUIDsto seach for.2.The SDP server responds with Service Search Response, which liststhe record handles that match the search pattern.3.If the record handle list is not empty, the client sends an AttributeSearch Request with a record handle and list of attributes to retrieve.4.The server responds with an Attribute Search Response with the valuefor each attribute requested by the client.4.1.7 RFCOMMRFCOMM is a supplementary, but commonly used, protocol in Bluetooth.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
