Hi Peter,
On Sun, 24 Jul 2011 17:26:24 +0100, Peter Hurley
<peter@xxxxxxxxxxxxxxxxxx> wrote:
Hi Sérgio,
On Wed, 2011-07-13 at 06:51 -0400, Sérgio Capela wrote:
Hello,
...
Is it possible to accept connections at the same time a inquiry is
running
or is the inquiry a blocking operation at the stack level? With two
adapters my server accepts remote connections and receives and sends
data
but when an inquiry is running it stops accepting connections. The
inquiry
is done in a separate thread.
That's handled in the controller at the baseband level. I don't know of
any controllers that will accept connections while in the Inquiry
substate - I'm not even sure if it's possible.
Why are you initiating discovery from the server-side?
Well, this is a test where I'm trying to see if content delivery is viable
through bluetooth and in this case the content depends on context. Imagine
a number of rooms which should serve differentiated content accordingly.
The server side discovery would try to automatically infer which content
should be delivered to a given possible client. For this purpose I perform
inquiries with rssi and thus the servers would act like tracking devices
which would transmit inquiry data to a central database. These are only
trials for now and I know that inquiries with rssi values are not that
good for this type of decision so in the future this operation can be
dropped in favor of other solution even if it end up as a choice at the
user side.
If you have to have server-side discovery, you could only perform
inquiry with one controller at a time. That way, the other controller's
available for new rfcomm connections (assuming your client load-balances
like that...).
Yep, that is what I'm doing. I bind one adapter to the rfcomm server and
use the other one for discovery and content delivery. The main process
thread is the accept server and both the inquiry and the content delivery
are done in threads launched for the purpose. I also made more tests
recently and what is happening is that as soon as the inquiry starts the
server stops accepting connections and starts processing inquiry result
events, however, after a couple of minutes I can see the server both
accepting and processing new connections and new inquiry result events.
The end result is that launching an inquiry leads me to loose possible
connections during a few minutes which is excessive for this case where
inquiries would be launched regularly.
Another question is related to a rfcomm client getting into D state and
thus not killable. Due to my setup (two adapters in the same computer) I
can use the computer as both the server and the client. For test
purposes
only I made a simple rfcomm client and I put it in a shell cycle thus
stressing the system regarding bluetooth connections. In this situation
the rfcomm client application becomes unresponsive after some time due
to
a non exiting disk sleep. I then end up with multiple instances of the
same application and I can't kill them. By launching the application
after
this I can see that the code blocks at a socket connection command
entering in a disk sleep state from which it doesn't exit. When this
happens I have to unplug the bluetooth adapter to get it working again
since it starts to give timeouts with hciconfig commands like "hciconfig
reset".
Any ideas about this? The problem itself is not serious since it
shouldn't
arise in normal conditions but it does require a reboot because of the
state D processes and makes the adapter unusable unless it is unplugged.
Although I'm not certain that they would fix the problem you're having,
I just posted a patch series that resolves some issues with lost wakeups
in rfcomm and l2cap. They need testing. You'd need patches 1~4 of 7.
Please feel free to reply direct regarding whether you can test these
and what that outcome was.
I suppose those patches would be available in the git sources right? At
the moment I can't test it but in a week or two I will try to compile the
sources and unless I encounter some problem I will reply in this topic.
Regards,
Sérgio
Regards,
Peter
--
Sérgio Capela
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
