[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bluetooth-dev] flow control


Does anybody out there have a good grasp of the flow control mechanisms
both in the Linux Bluetooth driver and the Bluetooth spec? Here's my
understanding, and some of it is guesswork:

1. LMP provides flow control at the bottommost level. But it can drop
packets after too many retries.
2. Flow control between the host and the h/w is available with HCI, but
by default the openbt stack doesn't use any in the h/w-to-host
3. None of the other protocols in the Bluetooth stack provide flow
control between their peers. RFCOMM seems to have mechanisms for it, but
they are not used by the Bluetooth spec?
4. Flow control from the Bluetooth line discipline to the lower layer
tty is used, but not vice versa?
5. No flow control between HCI, L2CAP and RFCOMM.
6. RFCOMM uses flow control with it's upper line discipline?

So here's my guess:

upper ldisc (e.g., ppp)
down/up: yes/yes
RCOMM <--- no/no --> peer RFCOMM
down/up: no/no
L2CAP <-- no/no --> peer L2CAP
down/up: no/no
HCI <-- no/yes --> peer HCI
down/up: yes/no
down/up: ?/? (depends... some h/w won't support it)
LMP <-- yes/yes --> peer LMP

But the same buffers are used all through HCI to RFCOMM, correct? So
flow control shouldn't be an issue between these layers?

I ask mainly because of the behaviour I saw while using cat between two
peer RFCOMM connections. If host A writes while host B is reading, data
is buffered. But if host A writes while host B is not reading, but
subsequently host B starts to read, some data could be missing.


To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com