Hi,
Is there any way to change (specifically - drastically shorten) the
amount of time a call to connect() blocks for whilst attempting to
connect to a remote device?
Hunting through the source, I've traced the delay back to
${KERNELSRC}/net/bluetooth/l2cap.c, specifically L2CAP_CONN_TIMEOUT,
which is defined as being 40 seconds in
/usr/include/bluetooth/bluetooth.h.
Ideally I'd like a sockopt available to tune that parameter on a
per-app basis. The application we're developing seeks to determine the
presence of a 'bunch' of devices by trying to connect and then sending
an L2CAP echo request packet before waiting for a valid response.
Moving to non-blocking connect() calls really isn't an option - the
problem isn't detecting multiple devices, it's the amount of time it
takes to ascertain whether a known device is present or not.
If I'm barking in the wrong forest, please feel free to boot me
elsewhere :-)
I'm using gentoo 2004.0 with linux-2.6.3-gentoo-r1 on x86.
Thanks in advance,
--
Mark Thompson/
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Aug 06, 2004, at 18:50, Andreas Gaufer wrote:
>
> I guess the timeout you are searching for is the page-time out. This
> timer is managed on the chip an can be changed with "hciconfig hciX
> pageto n" (if what your using is a usb device). man hciconfig also has
> a
> lot of info.
You're absolutely right.
Thanks for the pointer - client code fixed :)
Mark/
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Mark,
I think the 40 secounds you are talking about is the timeout the kernel
waits if no status is returned from the actual bt-chip connected to you
host (via HCI)
I guess the timeout you are searching for is the page-time out. This
timer is managed on the chip an can be changed with "hciconfig hciX
pageto n" (if what your using is a usb device). man hciconfig also has a
lot of info.
Greetings
Andy
On Fri, 6 Aug 2004 17:32:27 +0100
Mark Thompson <[email protected]> wrote:
> Hi,
>
> Is there any way to change (specifically - drastically shorten)
> the amount of time a call to connect() blocks for whilst
> attempting to connect to a remote device?
>
> Hunting through the source, I've traced the delay back to
> ${KERNELSRC}/net/bluetooth/l2cap.c, specifically L2CAP_CONN_TIMEOUT,
> which is defined as being 40 seconds in
> /usr/include/bluetooth/bluetooth.h.
>
> Ideally I'd like a sockopt available to tune that parameter on a
> per-app basis. The application we're developing seeks to determine
> the presence of a 'bunch' of devices by trying to connect and then
> sending an L2CAP echo request packet before waiting for a valid
> response.
>
> Moving to non-blocking connect() calls really isn't an option - the
> problem isn't detecting multiple devices, it's the amount of time it
> takes to ascertain whether a known device is present or not.
>
> If I'm barking in the wrong forest, please feel free to boot me
> elsewhere :-)
>
>
> I'm using gentoo 2004.0 with linux-2.6.3-gentoo-r1 on x86.
>
> Thanks in advance,
>
> --
> Mark Thompson/
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes
> on Linux.com, ITManagersJournal and NewsForge in the past few weeks?
> Now, one more big change to announce. We are now OSTG- Open Source
> Technology Group. Come see the changes on the new OSTG site.
> http://www.ostg.com_______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
--
Blue Cell Networks GmbH
Industriestra?e 1b
96163 Gundelsheim
Tel.: 0951-700 42 891 | Fax.: 0951-700 42 887
Diese Email sowie s?mtliche mit ihr ?bertragenen Dateien enthalten
vertrauliche und/oder rechtlich gesch?tzte Informationen, welche
lediglich f?r den/die Adressaten bestimmt sind. Sollten Sie nicht der
vorgesehene Empf?nger sein, ist Ihnen der Gebrauch, die Verbreitung oder
Vervielf?ltigung der darin enthaltenen Informationen nicht gestattet.
Sollten Sie nicht der vorgesehene Empf?nger sein, benachrichtigen Sie
den Absender bitte umgehend per Email und vernichten Sie die
Originalnachricht einschlie?lich etwaiger Kopien und angeh?ngter
Dateien. Vielen Dank.
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel