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
Hi Stefan,
> I've written a small library which uses the JNI to bring BlueZ to
> Java. Upon that, I'm writing a small "Location Aware
> Web-Service"-Demo. So my ClientApp has a DiscoveryThread which does
> non-cached inquiry and sdp_search() all the time, and an UpdateThread
> which uses the DiscoveryInfo to connect to the servers, measure RSSI
> and LQ and transmit the websites via L2CAP. Everything works fine
> while all devices are good in range, but if one device is at the edge
> of the range, sdp_search() blocks the DiscoveryThread and also seems
> to cripple/block the UpdateThread. I don't know why. I have seen that
> there is a hard coded 20s timeout in sdp_read_resp(). Is there a way
> to decrease this timeout or to make it a settable parameter in future
> versions? Anyway, sdp should not cripple l2cap, shold it? Any
> suggestions? Thanks in advance!
what do you mean by cripple L2CAP and use it concurrently. Explain in
more detail what your program is really doing and check how many low
level HCI connections are opened at the same time.
Regards
Marcel
-------------------------------------------------------
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
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel