Re: Implementation of name-resolve procedures in mgmtops

[Johan Hedberg <johan.hedberg@gmail.com>]

Hi Chen,

On Tue, Nov 01, 2011, Ganir, Chen wrote:
> Please keep in mind that if you do it 2 seconds, that will cause a
> problem. In interleaved scanning, we need to scan for BR/EDR devices
> for ~5 seconds ( T_GAP_100/2), and then LE devices for 5 seconds. If
> we wait 2 seconds for timeout, this means 2 seconds in which we do
> nothing. This will mean that we need to scan for BR/EDR for 1 second,
> wait 2 seconds for ack, and then we will have about 2 more seconds for
> name requests for legacy devices. We need to think of a better
> solution here, which will coexist with interleaved device discovery.

There must be something wrong with the spec or your understanding of it
since this doesn't make any sense to me. The only thing that would make
sense to me is if this 5 seconds only includes the inquiry phase but not
the name resolving phase. Typically BR/EDR devices have their page
timeout configured anywhere between 5 and 20 seconds. This means that
for a single BR/EDR device that happens to be out of range when the time
for name resolving comes, you could end up waiting quite long after the
inquiry phase. Even for devices within range 1 second isn't an unusual
time for name resolving, so you'd already go over 5 seconds with just 5
pre-2.1 devices around you.

> What if we start name requests immediately after the inquiry is
> complete, according to what is already pending for name request (what
> the user has already confirmed for name request), and allow the user
> to confirm the name request for more devices up until we complete the
> name request process and return the SCAN_COMPLETE event?

I don't know what you mean by "SCAN_COMPLETE" event, but this is what we
can and should certainly do. However if there was a single device found
for which we do not know the name, then the "pending" list will be empty
and in the worst case we'll end up waiting for whatever we decide to use
as a timeout. Note that this is not something that will always or even
frequently happen. In most cases inquiry results come well before the
inquiry complete and if the system isn't under really heavy load the
kernel will receive its ack in much shorter time.

Johan