Re: [Bluez-devel] sdp_search and l2cap concurrently

[Stefan Mischke <survivor@uni-paderborn.de>]

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