[Bluez-devel] Protocols over Bluetooth Baseband and disabiling Retransmissions

[Bluez-devel] Protocols over Bluetooth Baseband and disabiling Retransmissions

[Jim Wyllie]

I am attempting to run an experimental protocol on top of a Bluetooth 
connection to test our theories of reliability vs. the standard 
Bluetooth retransmission scheme (mainly ARQ retransmissions).  We're 
using BlueZ on Linux 2.6.12.5 to test this.

I would like to "break" the retransmission mechanism for L2CAP Packets 
(I am forced to use Java and JSR-82 for my testing, so I'm restricted to 
L2CAP as the lowest accessible layer).  I looked through 
[include/]net/bluetooth/l2cap.[hc] and the Bluetooth spec, and I could 
easily set the default flush_to to 0x0001 (.625 milliseconds should be 
effectively 0, and with no packet to retransmit, it should timeout the 
retransmission).  Am I on the right track, and would just changing all 
flush_to assignments to 0x0001 (including the default) work like I think 
it would?  If I'm not on the right track, could someone point me to a 
good way to achieve this?

Also, I looked into other solutions, such as shoe-horning Broadcast 
packets to do this, but Java doesn't seem to support it.  I also 
couldn't find a Java interface for SCO/e-SCO where I could frame my own 
packets in the stream (not that that's a very good way to do it, IMHO). 
  Anyone have any $.02 that he or she would like to offer to this?

Many thanks for your help,
Jim Wyllie
IRG Lab
Ohio University


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Protocols over Bluetooth Baseband and disabiling Retransmissions

[Albert Huang]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

I would like to "break" the retransmission mechanism for L2CAP Packets

> (I am forced to use Java and JSR-82 for my testing, so I'm restricted to
> L2CAP as the lowest accessible layer). I looked through
> [include/]net/bluetooth/l2cap.[hc] and the Bluetooth spec, and I could
> easily set the default flush_to to 0x0001 (.625 milliseconds should be
> effectively 0, and with no packet to retransmit, it should timeout the
> retransmission). Am I on the right track, and would just changing all
> flush_to assignments to 0x0001 (including the default) work like I think
> it would? If I'm not on the right track, could someone point me to a


You do want to set the flush timeout for the l2cap socket, but you don't
want to use l2cap_options.flush_to. That parameter is not actually used yet
in the kernel (Marcel, please correct me if I'm wrong and you've changed
this lately).

See here for an example on how to set the flush timeout:

http://people.csail.mit.edu/albert/bluez-intro/x556.html#bzi-l2cap-unreliable

Regards,
Albert

[-- Attachment #2: Type: text/html, Size: 1408 bytes --]

Re: [Bluez-devel] Protocols over Bluetooth Baseband and disabiling Retransmissions

[Steven Singer]

Jim Wyllie wrote:
> [include/]net/bluetooth/l2cap.[hc] and the Bluetooth spec, and I could 
> easily set the default flush_to to 0x0001 (.625 milliseconds should be 
> effectively 0, and with no packet to retransmit, it should timeout the 
> retransmission).  Am I on the right track, and would just changing all 
> flush_to assignments to 0x0001 (including the default) work like I think 
> it would?  If I'm not on the right track, could someone point me to a 
> good way to achieve this?

With BT 1.2 devices this probably won't do what you want. In 1.2, the
flush timeout starts at the point at which the packet is received over
the host transport. A 625 us timeout will probably expire before the
packet makes it as far as the radio.

A 1.1 device might do the right thing as the timeout starts at the
point at which the packet is first sent on the radio.

Note, however, that the flush timeout applies to all the packets on a
given ACL handle, not just to a single L2CAP CID. This means that the
L2CAP signalling is affected by the flush timeout. This is usually
highly undersirable.

You may have to switch to the HCI interface to get the level of
control you want which means JSR-82 probably won't be sufficient.

	- Steven
-- 


This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel