linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] multiple rfcomm listeners
Date: Sun, 27 Nov 2005 19:33:30 +0100	[thread overview]
Message-ID: <1133116410.13629.6.camel@blade> (raw)
In-Reply-To: <Pine.LNX.4.33.0511271455120.20980-100000@redbean.intranet.gw-instruments.de>

Hi Peter,

> > I've heard that bluetooth clients are supposed to check for the SP
> > channel via sdp on every connect, but bluez doesn't do that in its
> > rfcomm bindings, eh? Do other devices check the channel only when pairing?
> This behaviour is completly implementation depended. The Widcom stack and
> even some other implementaions do request the server channel number for a
> service just before connection setup. Other implementations just store the
> server channel during pairing. The SDP variant has the problem that it is
> not realy possible to distinguish between two identical services which
> only have different server channels, e.g. many mobile phones and some
> other devices offer two SPP channels. With the SDP variant it is likely
> that you connect to the wrong service.
> The pairing variant has the drawback that you can not connect to a service
> anymore if its server channel changes dynamicly. This again is
> implementation depoendent on the client side. However, most devices I'm
> aware off use fixed server channels.

this is a problem with the Bluetooth specification and its qualication.
The SDP defines a time-to-live for the service record, but nobody uses
it. However I can remember what's the default behavior if this attribute
doesn't exists.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2005-11-27 18:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-27  6:42 [Bluez-devel] multiple rfcomm listeners Brad Midgley
2005-11-27 14:05 ` Peter Wippich
2005-11-27 18:33   ` Marcel Holtmann [this message]
2005-11-27 21:14     ` Brad Midgley
2005-11-27 21:47       ` Marcel Holtmann
2005-11-27 21:59         ` Brad Midgley
2005-11-27 22:08           ` Marcel Holtmann
2005-11-27 22:25             ` Brad Midgley
2005-11-27 23:19               ` Marcel Holtmann

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=1133116410.13629.6.camel@blade \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).