From owner-freebsd-bluetooth@FreeBSD.ORG Sat Nov 8 09:17:24 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58D7E106567F for ; Sat, 8 Nov 2008 09:17:24 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp01.one2one.net (smtp01.one2one.net [149.254.200.196]) by mx1.freebsd.org (Postfix) with ESMTP id E68C08FC18 for ; Sat, 8 Nov 2008 09:17:23 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1KyjwV-0007ct-9h; Sat, 08 Nov 2008 09:17:19 +0000 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29061-06; Sat, 8 Nov 2008 09:17:18 +0000 (GMT) Received: from [10.34.38.217] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1KyjwT-0007co-0x; Sat, 08 Nov 2008 09:17:18 +0000 Received: (nullmailer pid 479 invoked by uid 1000); Sat, 08 Nov 2008 09:16:09 -0000 Date: Sat, 8 Nov 2008 09:16:09 +0000 (GMT) To: Guido Falsi In-Reply-To: <4914E54B.4060206@madpilot.net> References: <20081104111947.GB62907@megatron.madpilot.net> <1225799105.807983.1164.nullmailer@galant.ukfsn.org> <20081104135107.GA64776@megatron.madpilot.net> <1225821264.107584.759.nullmailer@galant.ukfsn.org> <4910B6E6.7070206@madpilot.net> <4910CA97.6030708@madpilot.net> <1226091521.039371.399.nullmailer@galant.ukfsn.org> <4914B113.60303@madpilot.net> <1226097099.328979.788.nullmailer@galant.ukfsn.org> <4914E54B.4060206@madpilot.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1226135769.665964.502.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on smtpbarns01); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: RFComm behaviour with nokia mobiles 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: Sat, 08 Nov 2008 09:17:24 -0000 On Sat, 8 Nov 2008, Guido Falsi wrote: > I have this code(I hope mozilla will not mangle this too much): > > uint32_t attrs[] = > { > SDP_ATTR_RANGE( > SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID+SDP_ATTR_SERVICE_NAME_OFFSET, > SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID+SDP_ATTR_SERVICE_NAME_OFFSET), > SDP_ATTR_RANGE( > SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST, > SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST), > }; > > so I define 2 ranges with a single attribute in each. This one defines the > order in which objects are returned. although the sdp lib function does collapse empty ranges into single attributes to save space in the outgoing request.. > I think FreeBSD's sdp is making 2 requests in this case...Or maybe forcing the > order to be the same as the request. No, it does use a single ServiceSearchAttribute but I think its just that the Nokia server iterates over the AttributeIDList with a pass through the server record each time for attributes that match: for (i = 0; i < ail_length; i++) for (j = 0; j < record_length; j++) if (ail[i] == rec[j]) add_attribute(rec[j]) break; Because both lists are supposed to be in ascending order though, it is possible to cut that down to a single pass with an eye on each list: i = 0, j = 0 next: if (ail[i] == rec[j]) add_attribute(rec[j]); i++, j++; else if (ail[i] < rec[j]) i++; else if (ail[i] > rec[j]) j++; if (i == ail_length) goto done; if (j == rec_length) goto done; goto next; done: Which is less processor intensive, and often with an embedded device (perhaps not in the modern world :) it is even easier to just hardwire such a search and probably that is what they are providing for in the spec. One thing that the current library code does not provide for is that the ServiceSearchAttribute response is parsed into the sdp_attr_t array but the caller has no way to know which record each attribute came from, so that can cause problems when more than one record is matched. You might also want to consider the case where a Serial Port service is matched that does not have a Service Name field. Do you match it or ignore it? iain PS all pseudo code comes with no guarantee of correctness! PPS wtf is "m-Router connectivity" anyway?