From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4146FD1E.9090100@uni-paderborn.de> Date: Tue, 14 Sep 2004 16:15:58 +0200 From: Stefan Mischke MIME-Version: 1.0 To: Marcel Holtmann CC: BlueZ Mailing List Subject: Re: [Bluez-devel] sdp_search and l2cap concurrently References: <41430846.4010006@uni-paderborn.de> <1094997749.5695.13.camel@pegasus> In-Reply-To: <1094997749.5695.13.camel@pegasus> Content-Type: text/html; charset=us-ascii List-ID: Please forget this one. My fault. Sorry!

Marcel Holtmann schrieb:
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
From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4144634E.4070404@uni-paderborn.de> Date: Sun, 12 Sep 2004 16:55:10 +0200 From: Stefan Mischke MIME-Version: 1.0 To: Marcel Holtmann CC: BlueZ Mailing List Subject: Re: [Bluez-devel] sdp_search and l2cap concurrently References: <41430846.4010006@uni-paderborn.de> <1094997749.5695.13.camel@pegasus> In-Reply-To: <1094997749.5695.13.camel@pegasus> Content-Type: text/plain; charset=ISO-8859-1; format=flowed List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [Bluez-devel] sdp_search and l2cap concurrently From: Marcel Holtmann To: Stefan Mischke Cc: BlueZ Mailing List In-Reply-To: <41430846.4010006@uni-paderborn.de> References: <41430846.4010006@uni-paderborn.de> Content-Type: text/plain Message-Id: <1094997749.5695.13.camel@pegasus> Mime-Version: 1.0 Sender: bluez-devel-admin@lists.sourceforge.net Errors-To: bluez-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 12 Sep 2004 16:02:29 +0200 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 Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <41430846.4010006@uni-paderborn.de> From: Stefan Mischke MIME-Version: 1.0 To: BlueZ Mailing List Content-Type: text/html; charset=us-ascii Subject: [Bluez-devel] sdp_search and l2cap concurrently Sender: bluez-devel-admin@lists.sourceforge.net Errors-To: bluez-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 11 Sep 2004 16:14:30 +0200 Hi!

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!

Kind regards
Stefan Mischke

------------------------------------------------------- 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 Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel