public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Till Harbaum <harbaum@beecon.de>
Cc: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] L2CAP dropping packets on BlueZ based receiver
Date: Mon, 02 Aug 2004 20:57:07 +0200	[thread overview]
Message-ID: <1091472875.4259.6.camel@pegasus> (raw)
In-Reply-To: <200408021859.44496.harbaum@beecon.de>

Hi Till,

> i have been using bluez l2cap for quite some time now. To my BlueMP3 receiver 
> i have streamed gigabytes via l2cap with no problems using bluez as a sender 
> so far.
> 
> A customer of mine now told me, that l2cap under bluez is unrealible. It was 
> hard to believe, but the follwing archive contains to little programs i wrote 
> to verify this. It's a sender and a (artifically slowed down) receiver:
> 
> http://www.harbaum.org/till/l2flow.tgz
> 
> The sender is marking the packets with some sequence number. After about 
> 80kBytes the receiver starts complaining about missing sequence numbers. 
> Since i can stream to my won hardware (and successfully slowing down the 
> transmission, since the receiving mp3 decoder is only taking the data at the 
> appropriate bandwidth) i am sure that sending data with bluez is not the 
> problem. However the receiver seems to fetch all packets from its bluetooth 
> hardware and is dropping packets if it then sees, that it has run out of 
> internal buffers.
> 
> Why is that? Can this be avoided? Is this by purpose?

the L2CAP of the Bluetooth 1.1 specification has no flow control and so
it can't be fully reliable. See the comment the l2cap.c source code:

        /* If socket recv buffers overflows we drop data here
         * which is *bad* because L2CAP has to be reliable.
         * But we don't have any other choice. L2CAP doesn't
         * provide flow control mechanism. */

Some Bluetooth stacks emulate L2CAP flow control with the flow control
of the HCI layer, but this is more bad than dropping a packet. Actually
this is the reason why most mobiles phones don't support more than one
ACL at the same time.

The solution for this is using RFCOMM or L2CAP with retransmission and
flow control from the Bluetooth 1.2 specification.

Regards

Marcel




-------------------------------------------------------
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. www.ostg.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2004-08-02 18:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-02 16:59 [Bluez-devel] L2CAP dropping packets on BlueZ based receiver Till Harbaum
2004-08-02 18:57 ` Marcel Holtmann [this message]
2004-08-03 10:23   ` Till Harbaum
2004-08-03 11:24     ` Marcel Holtmann
2004-08-03 12:16       ` Till Harbaum
2004-08-03 13:09         ` Marcel Holtmann
2004-08-03 13:29           ` Till Harbaum
2004-08-03 13:45             ` Marcel Holtmann
2004-08-04 15:24               ` [Bluez-devel] Disconnection Time Out Talbi
2004-08-04 22:24                 ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1091472875.4259.6.camel@pegasus \
    --to=marcel@holtmann.org \
    --cc=bluez-devel@lists.sourceforge.net \
    --cc=harbaum@beecon.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox