From owner-freebsd-bluetooth@FreeBSD.ORG Sun Jun 18 07:04:59 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C3D116A479 for ; Sun, 18 Jun 2006 07:04:59 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08E8B43D46 for ; Sun, 18 Jun 2006 07:04:58 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: from rya-online.net (du213-130-142-51.as15444.net [213.130.142.51]) by mail.ukfsn.org (Postfix) with SMTP id 3281FE70D6; Sun, 18 Jun 2006 08:04:45 +0100 (BST) Received: (nullmailer pid 22481 invoked by uid 1000); Sat, 17 Jun 2006 19:08:07 -0000 Date: Sat, 17 Jun 2006 20:08:06 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: <44931C12.7020805@savvis.net> References: <1150200307.649295.228.nullmailer@galant.ukfsn.org> <44904A60.6080105@savvis.net> <1150322381.757072.1713.nullmailer@galant.ukfsn.org> <4492E9FA.2030708@savvis.net> <1150486990.380039.25644.nullmailer@galant.ukfsn.org> <44931C12.7020805@savvis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1150571287.231614.2893.nullmailer@galant.ukfsn.org> From: Iain Hibbert Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 07:04:59 -0000 On Fri, 16 Jun 2006, Maksim Yevmenkin wrote: > i'm not sure why is it required to parse all the data and re-pack it into the > linked list, just to have another api that would search and extract data from > the linked list. I agree, and I dont like the plethora of functions that they use. Better I think to have a generic function and pass it an argument telling it what to look for, that way its easily extensible. > i had a chance to work with csr bluelab sdk recently and develop the I guess this is a proprietary system, but do they have a public API? My thought for a parse function would be to pass an array of some kind, describing the attributes and possible values that are wanted, plus the address of the storage location, so to find the HID control and interrupt PSM values you just go something like this: uint16_t control_psm, interrupt_psm; sdp_parse_t values[] = { { SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST, { UUID, SDP_UUID_PROTOCOL_L2CAP }, { UINT16, &control_psm } }, { SDP_ATTR_ADDITIONAL_PROTOCOL_DESCRIPTOR_LIST, { UUID, SDP_UUID_PROTOCOL_L2CAP }, { UINT16, &interrupt_psm } } }; nvalues = 2; control_psm = 0; interrupt_psm = 0; err = sdp_parse(pdu, &values, nvalues); if (err || control_psm == 0 || interrupt_psm == 0) ... and this should be easily extensible for whatever you want to extract. The array can be static and const. It could be that you could specify mandatory/optional values and have the sdp_parse fail if mandatory fields are not accounted for. I didnt think about it too deeply, just the general concept. There can no doubt be a bunch of complications.. and thinking about it, if the same concept could be used to *construct* a PDU I would be especially pleased.. iain From owner-freebsd-bluetooth@FreeBSD.ORG Mon Jun 19 17:19:45 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA7B016A47D for ; Mon, 19 Jun 2006 17:19:45 +0000 (UTC) (envelope-from maksim.yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABF6C43D6E for ; Mon, 19 Jun 2006 17:19:38 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id B9F3F3BF27; Mon, 19 Jun 2006 12:19:37 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19112-01-29; Mon, 19 Jun 2006 12:19:37 -0500 (CDT) Received: from [10.254.186.111] (sntc04ep01.savvis.net [64.14.1.106]) by mailgate1b.savvis.net (Postfix) with ESMTP id 29AA93BF09; Mon, 19 Jun 2006 12:19:37 -0500 (CDT) Message-ID: <4496DCA8.2070405@savvis.net> Date: Mon, 19 Jun 2006 10:19:36 -0700 From: Maksim Yevmenkin User-Agent: Thunderbird 1.5.0.2 (X11/20060603) MIME-Version: 1.0 To: Iain Hibbert References: <1150200307.649295.228.nullmailer@galant.ukfsn.org> <44904A60.6080105@savvis.net> <1150322381.757072.1713.nullmailer@galant.ukfsn.org> <4492E9FA.2030708@savvis.net> <1150486990.380039.25644.nullmailer@galant.ukfsn.org> <44931C12.7020805@savvis.net> <1150571287.231614.2893.nullmailer@galant.ukfsn.org> In-Reply-To: <1150571287.231614.2893.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at savvis.net Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 17:19:45 -0000 Iain, >> i'm not sure why is it required to parse all the data and re-pack it into the >> linked list, just to have another api that would search and extract data from >> the linked list. > > I agree, and I dont like the plethora of functions that they use. Better > I think to have a generic function and pass it an argument telling it what > to look for, that way its easily extensible. after thinking about it, i'm somewhat confused by your statement "...telling it what to look for...". please read below for the specific example. >> i had a chance to work with csr bluelab sdk recently and develop the > > I guess this is a proprietary system, but do they have a public API? yes it is a proprietary system. i'm not aware of any public api, however, i will describe my ideas at the end of this email. like i said before, those ideas have common points with csr api. > My thought for a parse function would be to pass an array of some kind, > describing the attributes and possible values that are wanted, plus the > address of the storage location, so to find the HID control and interrupt > PSM values you just go something like this: > > uint16_t control_psm, interrupt_psm; > > sdp_parse_t values[] = { > { > SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST, > { UUID, SDP_UUID_PROTOCOL_L2CAP }, > { UINT16, &control_psm } > }, > { > SDP_ATTR_ADDITIONAL_PROTOCOL_DESCRIPTOR_LIST, > { UUID, SDP_UUID_PROTOCOL_L2CAP }, > { UINT16, &interrupt_psm } > } > }; > > nvalues = 2; > control_psm = 0; > interrupt_psm = 0; > > err = sdp_parse(pdu, &values, nvalues); > > if (err || control_psm == 0 || interrupt_psm == 0) > ... > > and this should be easily extensible for whatever you want to extract. The > array can be static and const. It could be that you could specify > mandatory/optional values and have the sdp_parse fail if mandatory fields > are not accounted for. i see. this is one way of doing it. few comments. 1) i do not think that sdp_parse_t array could be static (and/or const) unless all the pointers to data holders are also static. also both sdp_data_t array and data pointers would have to be defined in the scope. not that it is an issue - one can wrap up sdp_parse() into another function that accepts data pointers and creates sdp_parse_t array on the stack 2) from what i understand, libsdp(3) must know how to parse attribute given in sdp_parse_t. in other words, libsdp(3) must know that SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST is a sequence in a specific format, etc. i think this means that if there is a new attribute and/or value format libsdp(3) needs modification. it all boils down to what do we think libsdp(3) is. is it a) a generic library that only operates inside the sdp protocol scope, i.e. it is only aware of sdp data elements and their types and *NOT* of the meaning of these data elements to the end user application or b) a library that has complete awareness of all currently defined (in all bluetooth profile documents) sdp attributes, their data types, format and values > I didnt think about it too deeply, just the general concept. There can no > doubt be a bunch of complications.. and thinking about it, if the same > concept could be used to *construct* a PDU I would be especially pleased.. right, please let me briefly describe what i had in mind for libsdp(3) parsing. this would correspond to the item (a) from above. there is a new auxiliary data type that represents a part of the original buffer (with sdp pdu). lets call it a "chunk". a chunk could be just 2 pointers to beginning and end. each chunk contains only one sdp data element. sdp data element could be simple, i.e. bool, int8,16,32 etc. or complex, i.e. seq8,16,32,alt8,etc. for example, uint16 chunk containing 0x0000 data value would have 3 bytes, i.e. "0x09 0x00 0x00". each chunk obviously "knows" about its type and length. access methods: 1) int32_t sdp_chunk_next(void const *pdu, void const *pdu_end, chunk_t *chunk); can be used to iterate through all chunks in the pdu, i.e. === chunk_t chunk; int32_t result; for (result = sdp_chunk_next(pdu, pdu_end, &chunk); result > 0; result = sdp_chunk_next(chunk.end + 1, pdu_end, &chunk)) { ... } === 2) uint8_t sdp_chunk_type(chunk_t *chunk) { return (chunk.begin[0]); } can be used to get chunk type. 3) for "simple" chunks, there are data extraction methods, i.e. int32_t sdp_chunk_get_{u}int{8,16,32}(chunk_t *chunk, {u}int{8,16,32} *value); you can also image the reverse api to build chunks, i.e. sdp_chunk_put_XXX() and sdp_chunk_advance() etc. obviously libsdp(3) can (and probably should) include more high-level functions to parse "well-known" attributes and their values. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Mon Jun 19 20:29:26 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9529F16A479 for ; Mon, 19 Jun 2006 20:29:26 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0563843D4C for ; Mon, 19 Jun 2006 20:29:25 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: from rya-online.net (du213-130-141-150.as15444.net [213.130.141.150]) by mail.ukfsn.org (Postfix) with SMTP id 773A9E7049; Mon, 19 Jun 2006 21:28:59 +0100 (BST) Received: (nullmailer pid 29478 invoked by uid 1000); Mon, 19 Jun 2006 20:25:05 -0000 Date: Mon, 19 Jun 2006 21:25:05 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: <4496DCA8.2070405@savvis.net> References: <1150200307.649295.228.nullmailer@galant.ukfsn.org> <44904A60.6080105@savvis.net> <1150322381.757072.1713.nullmailer@galant.ukfsn.org> <4492E9FA.2030708@savvis.net> <1150486990.380039.25644.nullmailer@galant.ukfsn.org> <44931C12.7020805@savvis.net> <1150571287.231614.2893.nullmailer@galant.ukfsn.org> <4496DCA8.2070405@savvis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1150748705.972874.2334.nullmailer@galant.ukfsn.org> From: Iain Hibbert Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 20:29:26 -0000 On Mon, 19 Jun 2006, Maksim Yevmenkin wrote: [I chopped the order a bit] > it all boils down to what do we think libsdp(3) is. is it > > a) a generic library that only operates inside the sdp protocol scope, i.e. it > is only aware of sdp data elements and their types and *NOT* of the meaning of > these data elements to the end user application Yes, thats what I would like (I think we concur).. > b) a library that has complete awareness of all currently defined (in all > bluetooth profile documents) sdp attributes, their data types, format and > values and I dont like this type of system.. > obviously libsdp(3) can (and probably should) include more high-level > functions to parse "well-known" attributes and their values. and I think it would be nice if this was not necessary for ease of use. > after thinking about it, i'm somewhat confused by your statement "...telling > it what to look for...". ... > 2) from what i understand, libsdp(3) must know how to parse attribute given in > sdp_parse_t. in other words, libsdp(3) must know that > SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST is a sequence in a specific format, etc. i > think this means that if there is a new attribute and/or value format > libsdp(3) needs modification. No, my thought was to provide a fairly simple 'description' of the problem that you want solved. eg First, we tell the server, we are interested a particular service (eg DUN) and we get the PDU from the server. The PDU can be opaque for all we care, or it can be an array of attributes as is currently the case or flat as you suggested earlier. Thats not so important (I'm considering it opaque since as a client I dont want to parse it myself) So, if the description goes like this for ATTRIBUTE=PROTOCOL_DESCRIPTOR_LIST, we want to find UUID RFCOMM INT8 =>
it scans the PDU and for each attribute looks at its list to see if it has anything for that attribute ID. When it has something, it scans the attribute chunk using the list we gave it - ie, in this case, for the PROTOCOL_DESCRIPTOR_LIST attribute it first wants to find a UUID matching RFCOMM before it can proceed, then it must find an INT8 value which it stores in the address given. When all the attributes are parsed, it returns and you just examine the addresses you gave it to see if contents have been updated. > right, please let me briefly describe what i had in mind for libsdp(3) > parsing. this would correspond to the item (a) from above. This is good and is necessary in any case, but my thought is that it still throws a lot of the parsing and interpretation onto the client program so I would like to take a step further. So far as I can see, it should be possible to parse the PDU without needing to know the complete structure as unknown portions can easily be skipped. The 'descriptor' language would obviously have to be a little more complex than as described above, but since any client would usually only want to parse a particular type of service then if it can be defined in a static structure manner that makes it easy to program and it should be clear to see what it is extracting from where. If it turns out that providing a bunch of macros to construct the descriptor 'program' dynamically is easier and neater then thats Ok too.. iain From owner-freebsd-bluetooth@FreeBSD.ORG Mon Jun 19 22:42:22 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B9D216A474 for ; Mon, 19 Jun 2006 22:42:22 +0000 (UTC) (envelope-from maksim.yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD93C43D45 for ; Mon, 19 Jun 2006 22:42:21 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 522C13BF09; Mon, 19 Jun 2006 17:42:20 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30186-01-2; Mon, 19 Jun 2006 17:42:20 -0500 (CDT) Received: from [10.254.186.111] (sntc04ep01.savvis.net [64.14.1.106]) by mailgate1b.savvis.net (Postfix) with ESMTP id 879F33BF3B; Mon, 19 Jun 2006 17:42:19 -0500 (CDT) Message-ID: <4497284A.90609@savvis.net> Date: Mon, 19 Jun 2006 15:42:18 -0700 From: Maksim Yevmenkin User-Agent: Thunderbird 1.5.0.2 (X11/20060603) MIME-Version: 1.0 To: Iain Hibbert References: <1150200307.649295.228.nullmailer@galant.ukfsn.org> <44904A60.6080105@savvis.net> <1150322381.757072.1713.nullmailer@galant.ukfsn.org> <4492E9FA.2030708@savvis.net> <1150486990.380039.25644.nullmailer@galant.ukfsn.org> <44931C12.7020805@savvis.net> <1150571287.231614.2893.nullmailer@galant.ukfsn.org> <4496DCA8.2070405@savvis.net> <1150748705.972874.2334.nullmailer@galant.ukfsn.org> In-Reply-To: <1150748705.972874.2334.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at savvis.net Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 22:42:22 -0000 Iain, >> it all boils down to what do we think libsdp(3) is. is it >> >> a) a generic library that only operates inside the sdp protocol scope, i.e. it >> is only aware of sdp data elements and their types and *NOT* of the meaning of >> these data elements to the end user application > > Yes, thats what I would like (I think we concur).. ah, good :) >> obviously libsdp(3) can (and probably should) include more high-level >> functions to parse "well-known" attributes and their values. > > and I think it would be nice if this was not necessary for ease of use. sure >> after thinking about it, i'm somewhat confused by your statement "...telling >> it what to look for...". > > ... > >> 2) from what i understand, libsdp(3) must know how to parse attribute given in >> sdp_parse_t. in other words, libsdp(3) must know that >> SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST is a sequence in a specific format, etc. i >> think this means that if there is a new attribute and/or value format >> libsdp(3) needs modification. > > No, my thought was to provide a fairly simple 'description' of the problem > that you want solved. > > eg > > First, we tell the server, we are interested a particular service (eg DUN) > and we get the PDU from the server. The PDU can be opaque for all we care, > or it can be an array of attributes as is currently the case or flat as > you suggested earlier. Thats not so important (I'm considering it opaque > since as a client I dont want to parse it myself) > > So, if the description goes like this > > for ATTRIBUTE=PROTOCOL_DESCRIPTOR_LIST, we want to find > UUID RFCOMM > INT8 =>
> > it scans the PDU and for each attribute looks at its list to see if it has > anything for that attribute ID. When it has something, it scans the > attribute chunk using the list we gave it - ie, in this case, for the > PROTOCOL_DESCRIPTOR_LIST attribute it first wants to find a UUID matching > RFCOMM before it can proceed, then it must find an INT8 value which it > stores in the address given. When all the attributes are parsed, it > returns and you just examine the addresses you gave it to see if contents > have been updated. ah, ok, i think, i missed you point in earlier emails. so, just to make sure i understood you correctly this time :) you are suggesting to implement some sort of "mini-program" that sdp parser would "execute" and give you back the results. each sdp client then will have its own "mini-program" for sdp parser designed to parse sdp response and look for specified (by the "mini-program") attributes and values. >> right, please let me briefly describe what i had in mind for libsdp(3) >> parsing. this would correspond to the item (a) from above. > > This is good and is necessary in any case, but my thought is that it still > throws a lot of the parsing and interpretation onto the client program so > I would like to take a step further. So far as I can see, it should be > possible to parse the PDU without needing to know the complete structure > as unknown portions can easily be skipped. > > The 'descriptor' language would obviously have to be a little more complex > than as described above, but since any client would usually only want to > parse a particular type of service then if it can be defined in a static > structure manner that makes it easy to program and it should be clear to > see what it is extracting from where. > > If it turns out that providing a bunch of macros to construct the > descriptor 'program' dynamically is easier and neater then thats Ok too.. that is an interesting approach. i'm sure it is possible to do things this way. the only question arises is how much complexity would we like in this "mini-program"? lets consider the following example. a minimal "protocol descriptor list" for rfcomm based service would look something like seq8 len8 - 2 bytes seq8 len8 - 2 bytes uuid16 value16 - 3 bytes L2CAP seq8 len8 - 2 bytes uuid16 value16 - 3 bytes RFCOMM uint8 value8 - 2 bytes RFCOMM param #1 ========= 14 bytes as you know, rfcomm channel number is in so called "protocol specific parameter #1". lets say, for argument sake, the descriptor also has protocol specific parameter #2 and #3. and also say that a client in interested in value of protocol specific parameter #1 and #3 (i.e. skip #2) *if* #2 and #3 are present. because all values are simply uint8 there is no way to distinguish between them. now, lets assume that we can work around this problem by putting dummy parser "mini-program" data structure that says that we can have parameters #1, #2 and #3. data pointer for #2 is null, indicating that we do not care about the value. data pointers for #1 and #3 are not null. seems reasonable? may be. i looked at few profile documents (specifically sdp records), and, it seems that some profile may have optional attributes/values. so whatever the "language" we invent for sdp parsing, imo, should have some sort of conditional parsing. and, btw, i think, you were asking/suggesting if you could run rfcomm on different l2cap psm, and, in this case you would need to add uint16 psm parameter to l2cap protocol in the descriptor :) thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Wed Jun 21 18:06:35 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9DF616A47C for ; Wed, 21 Jun 2006 18:06:35 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8B8443D45 for ; Wed, 21 Jun 2006 18:06:34 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: from rya-online.net (du213-130-141-174.as15444.net [213.130.141.174]) by mail.ukfsn.org (Postfix) with SMTP id 1E671E6A97; Wed, 21 Jun 2006 19:05:58 +0100 (BST) Received: (nullmailer pid 166 invoked by uid 1000); Wed, 21 Jun 2006 18:02:30 -0000 Date: Wed, 21 Jun 2006 19:02:30 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: <4497284A.90609@savvis.net> References: <1150200307.649295.228.nullmailer@galant.ukfsn.org> <44904A60.6080105@savvis.net> <1150322381.757072.1713.nullmailer@galant.ukfsn.org> <4492E9FA.2030708@savvis.net> <1150486990.380039.25644.nullmailer@galant.ukfsn.org> <44931C12.7020805@savvis.net> <1150571287.231614.2893.nullmailer@galant.ukfsn.org> <4496DCA8.2070405@savvis.net> <1150748705.972874.2334.nullmailer@galant.ukfsn.org> <4497284A.90609@savvis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1150912950.571307.167.nullmailer@galant.ukfsn.org> From: Iain Hibbert Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 18:06:35 -0000 On Mon, 19 Jun 2006, Maksim Yevmenkin wrote: > that is an interesting approach. i'm sure it is possible to do things this > way. the only question arises is how much complexity would we like in this > "mini-program"? Yes, I didnt really think of it as a 'program' until my last message but maybe its clearer to consider it that way. Maybe more of a 'map' though, and I'm still not sure that it will work out properly, the details are likely to be in the implementation.. :) > lets consider the following example. a minimal "protocol descriptor list" for > rfcomm based service would look something like > > seq8 len8 - 2 bytes > seq8 len8 - 2 bytes > uuid16 value16 - 3 bytes L2CAP > seq8 len8 - 2 bytes > uuid16 value16 - 3 bytes RFCOMM > uint8 value8 - 2 bytes RFCOMM param #1 > ========= > 14 bytes > as you know, rfcomm channel number is in so called "protocol specific > parameter #1". lets say, for argument sake, the descriptor also has protocol > specific parameter #2 and #3. and also say that a client in interested in > value of protocol specific parameter #1 and #3 (i.e. skip #2) *if* #2 and #3 > are present. because all values are simply uint8 there is no way to > distinguish between them. now, lets assume that we can work around this > problem by putting dummy parser "mini-program" data structure that says that > we can have parameters #1, #2 and #3. data pointer for #2 is null, indicating > that we do not care about the value. data pointers for #1 and #3 are not null. > seems reasonable? exactly so > may be. i looked at few profile documents (specifically sdp records), > and, it seems that some profile may have optional attributes/values. so > whatever the "language" we invent for sdp parsing, imo, should have some > sort of conditional parsing. Yes, I think the best way to do that would be to split the program/map into segments with each labelled by the attribute that it refers to, then the parse routine just scans what it has and looks up each attribute in the list and tries to interpret what it has with the instructions it got. > and, btw, i think, you were asking/suggesting if you could run rfcomm on > different l2cap psm, and, in this case you would need to add uint16 psm > parameter to l2cap protocol in the descriptor :) I suspect its as you say though, and that most devices will not handle this properly, giving the PSM is not mentioned in any of the standard profile documents and so is unlikely to be handled properly. Still, most Bluetooth devices will not be supplying enough services to even use up the 30 server channels so maybe they wont need that for a while.. In fact, I get the feeling that SDP is capable of much more complex configuration than is mentioned in the profile documents. For instance, it says that if more than one kind of protocol stack can be used to access a service, then a data element alternative is used in the ProtocolDescriptorList - be very complex to support that kind of thing and eg in the Headset profile, it doesnt say anything about that, just says use RFCOMM over L2CAP. iain