From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] L2CAP retransmission, flow control
Date: Wed, 09 Feb 2005 11:18:26 +0100 [thread overview]
Message-ID: <1107944306.13863.15.camel@pegasus> (raw)
In-Reply-To: <1107940961.9489.32.camel@mammoth.research.nokia.com>
Hi Imre,
> > Feel free to start. I am happy to get L2CAP 1.2 support included. The
>
> Ok, we'll have already some basic stuff to support the new config
> options, I'll start then to implement the rest. L2CAP QoS could also be
> done at some point, for the moment I don't plan to add support to
> anything but 'best effort'.
don't worry too much about QoS at the moment.
> > L2CAP options now contain a mode value and this is exactly for this
> > purpose. Let the rest of the RFC config values be the defaults from the
> > specification by now. Another way to activate RFC would be to use the
> > SOCK_STREAM socket type.
> >
>
> Yes, I agree. Is it ok then to do the following?
>
> For SOCK_STREAM try to negotiate RFC, if peer doesn't accept use basic
> mode.
If SOCK_STREAM is requested and RFC negotiation fails, then also the
connection must fail. For SOCK_STREAM you need flow control.
> For SOCK_DGRAM, SOCK_RAW try to negotiate FC, if peer doesn't accept
> use basic mode.
For SOCK_DGRAM and SOCK_RAW we don't do anything. The SOCK_DGRAM is for
connection-less channels and SOCK_RAW gives access to the signal channel
itself.
If you use SOCK_SEQPACKET (current type) and mode > 0 then negotiate RFC
and if success then use it, otherwise fail.
> Other issues I was thinking about:
>
> The 1.2 spec says it's possible for L2CAP to send incorrect packets
> (with missing fragments) to upper layers with indication of the
> incorrect parts of the given packet. The only possiblity I found so far,
> is to signal that L2CAP reliability can't be guaranteed any more and
> drop the packet.
> Is there a way or is there a case at all where we should support
> applications that need such incorrect packets?
I think it is bad idea to support this and we don't really need it. This
interaction between different layers is useless from my point.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2005-02-09 10:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-09 7:40 [Bluez-devel] L2CAP retransmission, flow control Imre Deak
2005-02-09 8:48 ` Marcel Holtmann
2005-02-09 9:22 ` Imre Deak
2005-02-09 10:18 ` Marcel Holtmann [this message]
2005-02-09 13:24 ` Imre Deak
2005-02-09 14:06 ` Marcel Holtmann
2005-02-09 17:04 ` Imre Deak
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=1107944306.13863.15.camel@pegasus \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.