Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 8 Nov 2008 09:16:09 +0000 (GMT)
From:      Iain Hibbert <plunky@rya-online.net>
To:        Guido Falsi <mad@madpilot.net>
Cc:        freebsd-bluetooth@freebsd.org
Subject:   Re: RFComm behaviour with nokia mobiles
Message-ID:  <1226135769.665964.502.nullmailer@galant.ukfsn.org>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1226135769.665964.502.nullmailer>