From: Marcel Holtmann <marcel@rvs.uni-bielefeld.de>
To: Max Krasnyansky <maxk@qualcomm.com>
Cc: Daryl Van Vorst <daryl@wideray.com>,
"'BlueZ Mailing List'" <bluez-devel@lists.sourceforge.net>
Subject: RE: [Bluez-devel] Qualification Testing
Date: 14 May 2003 01:19:50 +0200 [thread overview]
Message-ID: <1052867997.4608.23.camel@pegasus.local> (raw)
In-Reply-To: <5.1.0.14.2.20030513153902.0d3016d8@unixmail.qualcomm.com>
Hi Max,
> >> Hmm, ok :). But after thinking more about this I think that we probably still need
> >> some way to tell the apps that link became unreliable. I mean parsing syslogs is
> >> not very elegant solution :). Also even though Cetecom accepted it as a solution
> >> other BQBs might not.
> >>
> >> Here is what I had in mind. We could add L2CAP socket option L2CAP_RELIABILITY,
> >> which will be used by the apps that are "paranoid" :) about link reliability.
> >> Then whenever we receive corrupted L2CAP frame we'd check connected sockets, attached
> >> to this connection, that have this option enabled and signal error condition on them.
> >> i.e. read/recvmsg will return error. Application can then either clear that error with
> >> getsockopt(SO_ERROR) and continue or close the socket.
> >
> >the idea itself sounds very good. But I see no advantage in implementing
> >such kind of extra functionality. We can not detect if a frame is
> >currupt or not, because we have no checksum mechanism. The only thing we
> >can detect is a length mismatch. What about a corrupted cid?
> >If you notify the wrong socket and the application on that socket can't deal
> >with such an error.
> Definition of the L2CAP_RELAIBILITY option is rather broad :). In general it would mean
> "Notify me when you can no longer guaranty reliable transmission".
> You're right what we don't have checksum. But we can detect failures other than
> the wrong length. For example missing start frame or missing continuation frame.
> CID we're going to have to ignore because it doesn't necessarily mean that connection
> became unreliable.
> So there is no such thing as notifying the wrong socket in this case. If L2CAP detects
> that connection became unreliable it notifies all sockets on that connection (those
> that explicitly requested notification of course).
so if we detect a failure in an ACL packet, we notify all L2CAP
connections on the ACL link that have this option set. This sounds a
little bit better to me. I understand you wrong at the first time and
now I think we should have such extra stuff.
But I don't like the name and your meaning of this options. It sounds
like something that it is not and will never be. For the description of
this option I think it should be something like
"Notify me when you detect an error in the ACL payload"
And the option name can be L2CAP_CHECKACL. This is not very good, I
know, so any other proposals?
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2003-05-13 23:19 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-06 17:34 [Bluez-devel] Qualification Testing Daryl Van Vorst
2003-05-07 10:56 ` Stephen Crane
2003-05-07 16:44 ` Daryl Van Vorst
2003-05-08 2:18 ` Daryl Van Vorst
2003-05-12 16:37 ` Stephen Crane
2003-05-12 19:38 ` Daryl Van Vorst
2003-05-08 13:43 ` Marcel Holtmann
2003-05-08 18:11 ` Daryl Van Vorst
2003-05-08 19:53 ` Marcel Holtmann
2003-05-08 21:04 ` Daryl Van Vorst
2003-05-08 21:55 ` Daryl Van Vorst
2003-05-09 0:10 ` Marcel Holtmann
2003-05-08 22:06 ` Daryl Van Vorst
2003-05-08 18:33 ` Daryl Van Vorst
2003-05-09 0:51 ` Max Krasnyansky
2003-05-09 1:14 ` Marcel Holtmann
2003-05-09 18:11 ` Daryl Van Vorst
2003-05-09 18:36 ` Marcel Holtmann
2003-05-09 21:15 ` Max Krasnyansky
2003-05-09 21:52 ` Daryl Van Vorst
2003-05-09 22:51 ` Max Krasnyansky
2003-05-09 23:16 ` Daryl Van Vorst
2003-05-09 23:40 ` Daryl Van Vorst
2003-05-10 0:26 ` Marcel Holtmann
2003-05-10 2:33 ` Daryl Van Vorst
2003-05-10 6:17 ` Max Krasnyansky
2003-05-10 11:25 ` Marcel Holtmann
2003-05-11 3:57 ` Daryl Van Vorst
2003-05-12 22:51 ` Daryl Van Vorst
2003-05-12 23:05 ` Marcel Holtmann
2003-05-13 17:37 ` Max Krasnyansky
2003-05-13 17:55 ` Daryl Van Vorst
2003-05-13 22:31 ` Marcel Holtmann
2003-05-13 23:02 ` Max Krasnyansky
2003-05-13 23:19 ` Marcel Holtmann [this message]
2003-05-14 0:05 ` Max Krasnyansky
2003-05-14 0:30 ` Marcel Holtmann
2003-05-14 16:02 ` Daryl Van Vorst
2003-05-14 16:34 ` Max Krasnyansky
2003-05-14 21:12 ` Daryl Van Vorst
2003-05-14 22:24 ` Daryl Van Vorst
2003-05-14 22:27 ` Marcel Holtmann
2003-05-14 22:35 ` Daryl Van Vorst
2003-05-16 0:43 ` Max Krasnyansky
2003-05-16 14:43 ` Daryl Van Vorst
2003-05-16 17:38 ` Max Krasnyansky
2003-05-16 17:54 ` Daryl Van Vorst
2003-05-16 7:17 ` Marcel Holtmann
2003-05-10 6:16 ` Max Krasnyansky
2003-05-10 16:30 ` Marcel Holtmann
2003-05-11 7:19 ` Max Krasnyansky
2003-05-11 7:44 ` Marcel Holtmann
2003-05-12 23:37 ` Daryl Van Vorst
2003-05-13 0:04 ` Marcel Holtmann
2003-05-13 0:43 ` Daryl Van Vorst
2003-05-13 17:49 ` Max Krasnyansky
2003-05-13 17:44 ` Max Krasnyansky
2003-05-13 18:36 ` Daryl Van Vorst
2003-05-15 21:25 ` Daryl Van Vorst
2003-05-16 17:35 ` Max Krasnyansky
2003-05-16 18:01 ` Daryl Van Vorst
2003-05-16 18:23 ` Marcel Holtmann
2003-05-19 21:17 ` Max Krasnyansky
2003-05-19 21:19 ` Max Krasnyansky
2003-05-20 16:40 ` Daryl Van Vorst
2003-05-29 22:51 ` Daryl Van Vorst
2003-06-12 18:08 ` Max Krasnyansky
2003-06-12 18:49 ` Daryl Van Vorst
2003-06-12 19:11 ` Max Krasnyansky
2003-06-12 20:54 ` Daryl Van Vorst
2003-06-12 21:28 ` Marcel Holtmann
2003-06-13 1:22 ` Max Krasnyansky
2003-05-13 13:30 ` Daryl Van Vorst
2003-05-13 14:02 ` Marcel Holtmann
-- strict thread matches above, loose matches on Subject: below --
2004-12-01 0:32 [Bluez-devel] Qualification testing Daryl Van Vorst
2004-12-01 6:42 ` Marcel Holtmann
2004-12-01 19:09 ` Daryl Van Vorst
2004-12-01 19:32 ` Marcel Holtmann
2004-12-01 23:02 ` Daryl Van Vorst
2004-12-02 7:35 ` Marcel Holtmann
2004-12-02 17:56 ` Daryl Van Vorst
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=1052867997.4608.23.camel@pegasus.local \
--to=marcel@rvs.uni-bielefeld.de \
--cc=bluez-devel@lists.sourceforge.net \
--cc=daryl@wideray.com \
--cc=maxk@qualcomm.com \
/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