From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Inquiry cache management (clock offset)
Date: Wed, 20 Dec 2006 17:23:26 +0100 [thread overview]
Message-ID: <1166631806.17802.10.camel@violet> (raw)
In-Reply-To: <45896C24.2070106@pracucci.com>
Hi Marco,
> I have read a portion of bluez kernel sources and I have noticed, if I'm
> not wrong, that bluez looks up the inquiry cache before establish an ACL
> link, in order to get the clock offset of the remote device (returned
> from a previuos inquiry). This is a great features to speed up the
> paging process.
>
> However, the scope of the inquiry cache is bounded to the interface that
> do an inquiry. So, suppose that I have 2 interfaces: the "interface A"
> does an inquiry and, after, the "interface B" creates a baseband
> connection. This last interface (B) sends an HCI "create connection"
> command with the default clock offset instead of the real clock offset,
> as determined by interface A.
>
> Now, If we suppose that I can't inquiry and create the connection with
> the same interface, I think there are two solutions:
> - Kernel side: patch the kernel and let hci_inquiry_cache_lookup() to
> lookup the inquiry cache of each interface
> - Application side: create a baseband connection with
> hci_create_connection() before establish a L2CAP/RFCOMM communication
>
> What are the main advantages/disadvantages of the above solutions?
> Do you have any suggestion?
the main disadvantage is that it gives you nothing. You can't move the
clock offset around from adapter A to adapter B. As the word says, it is
a clock _offset_ and this means it depends on the local clock on the
chip. So a received clock offset on adapter A is invalid on adapter B
and it might happen that the connection establishment takes longer than
if you would have used no clock offset at all.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2006-12-20 16:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-20 17:00 [Bluez-devel] Inquiry cache management (clock offset) Marco Pracucci
2006-12-20 16:23 ` Marcel Holtmann [this message]
2006-12-20 17:30 ` Marco Pracucci
2006-12-21 6:26 ` Pierre-Yves Paulus
2006-12-21 12:53 ` Marcel Holtmann
2006-12-21 14:15 ` Cris
2006-12-21 15:12 ` Marco Pracucci
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1166631806.17802.10.camel@violet \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox