Date: Wed, 21 Jun 2006 19:02:30 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP Message-ID: <1150912950.571307.167.nullmailer@galant.ukfsn.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1150912950.571307.167.nullmailer>