Linux bluetooth development
 help / color / mirror / Atom feed
From: "Thor Egil Skaug" <paxtonrd@hotmail.com>
To: "'Steven Singer'" <steven.singer@csr.com>
Cc: <bluez-users@lists.sourceforge.net>
Subject: RE: [Bluez-users] AUX1 packets
Date: Mon, 1 Mar 2004 11:09:16 -0800	[thread overview]
Message-ID: <000601c3ffc0$b0e35cc0$46a57e40@thores> (raw)
In-Reply-To: <40437D65.9050004@csr.com>

>It's not clear to me how knowing the QoS settings for link will alter
what settings are best for the link, so it's not clear to me what your
middleware brings to the situation.

My research intends to enumerate mechanisms for QoS in wireless CORBA
transports - figuring out the switches in each standard that can be
toggeled to change the behavior of the wireless network. Then the
application designer (using CORBA) will decide on a type of wireless
network, and network requirements (these are generecized and not tied to
BT/IEEE8011.b etc). The middleware then takes these requirements and
uses the hooks specific to the wirless network to achieve what was
asked.

>You're trying to reinvent the wheel badly.

Thanks for the info on the received signal strenght versus the
transmission packet type. I didn't think of that. I could of course be
stubborn and say that if I wanted to let the application decide packet
types, I'd attach a byte of link quality to every message for the
receiver to use. But as you say, it is really reinventing the wheel
somewhat.

But if there are multiple CORBA server replicas, it could be interesting
to send each CORBA request to both servers, one link having packet
requirements, and the other letting CQDDR decide, then the client uses
the first reply and discards the other (in a CORBA client/server
application using BT).

More interesting: Is CQDDR implemented on all devices? I have a couple
that don't support reading RSSI/Link Quality?

Anyway, it makes some sence to me to try and force certain packet types,
since the system may have strict latency requirements, combining this
with flush timeouts for the connection.

Thor


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

  reply	other threads:[~2004-03-01 19:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-01 17:02 [Bluez-users] AUX1 packets Thor Egil Skaug
2004-03-01 18:13 ` Steven Singer
2004-03-01 19:09   ` Thor Egil Skaug [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-02-28 19:35 Thor Egil Skaug
2004-03-01 14:55 ` Marcel Holtmann
2004-03-01 15:44   ` Thor Egil Skaug
2004-03-01 15:58     ` Steven Singer
2004-03-01 16:07       ` Thor Egil Skaug
2004-03-01 16:18         ` Steven Singer

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='000601c3ffc0$b0e35cc0$46a57e40@thores' \
    --to=paxtonrd@hotmail.com \
    --cc=bluez-users@lists.sourceforge.net \
    --cc=steven.singer@csr.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