Re: sdp_search and l2cap concurrently

Hi Marcel!

Marcel Holtmann schrieb:

> what do you mean by cripple L2CAP and use it concurrently. Explain in
> more detail what your program is really doing 
Ok, I'll explain it in Pseudo-Code:

DiscoveryThread does all the time {
 InquiryInfo[] ii = do_inquiry();
 DiscoveryInfo[] di = sdp_filter_for(my_l2cap_service, ii);
 pass_to_UpdateThread(di):
}

UpdateThread does all the time {
 check_for_new_DiscoveryInfo_and_add_them_to(internal_di, di);
 do_for_all(di_item = internal_di[i]) {
   int sock = l2cap_connect(di_item);
   di_item.name = l2cap_read_descriptive_name(sock);
   di_item.content = l2cap_read_website_content(sock);
   di_item.rssi = hci_readRSSI(l2cap_sock2hci_conn(sock));
   di_item.lq = hci_getLinkQuality(l2cap_sock2hci_conn(sock));
   l2cap_close(sock);
   di_item.sum = evaluate(di_item.rssi, di_item.lq);
 }
 sort_by_sum(di_internal);
 show_nearest_website_content(di_internal[0]);
}

By "cripple" I mean if one device is almost out of range (l2cap 
connections would fail, but inquiry discovered it anyway) 
"sdp_filter_for(my_service, ii)" takes quite long to fail by timeout. 
And in this time, the UpdateThread doesn't seem to run eigther. The 
whole thing hangs. I think that is because all Java-Threads belong to 
only one Linux-Process which communicates with BlueZ. And this process 
is blocked by SDP for up to SDP_RESPONSE_TIMEOUT (see 
bluez-sdp/libs/utils.c, sdp_read_rsp(..)). I tried to lower this timeout 
by applying smaller timeouts SO_SNDTIMEO and SO_RCVTIMEO to the 
sdp_session's l2cap socket, but this doesn't seem to work because of the 
use of select().

In my opinion there are three ways to solve this:
1. Make SDP_RESPONSE_TIMEOUT a settable parameter
2. Don't use select(); instead put the socket to non-blocking state 
("fcntl(sock, F_SETFL, flags | O_NONBLOCK)") while connecting.
3. Don't use select(); instead let the user/programmer chose to put a 
SO_SNDTIMEO and SO_RCVTIMEO on the socket.

2. and 3. may be combined.

But probably, it is something quite different or there's an easy 
solution. I just wanted to ask for it :-). I'll test further...

> and check how many low
> level HCI connections are opened at the same time.
>  
I think there can only be one low level (ACL) connection to each device 
at a time. Unfortunately, I have only 3 devices for testing. So this 
can't be the problem.

Regards,
Stefan



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php