Re: A couple of questions related to a rfcomm server

Hi Peter,

On Sun, 24 Jul 2011 17:26:24 +0100, Peter Hurley  
[off-list ref] wrote:

Hi Sérgio,

On Wed, 2011-07-13 at 06:51 -0400, Sérgio Capela wrote:

quoted

Hello,

...

quoted

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.

quoted

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