[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [bluetooth-dev] Line collision between SDP and RF_COMM
On Mon, 4 Feb 2002 15:46:27 +0100 Anders_Torbjörn_Johansson
> > I think 'line' should be more related to baseband link, otherwise it
> > would waste the resources--the 'BT_NBR_DATAPORTS' is 7.
> Line is more a rfcomm concept, that's what the define is for to
> set up 7 tty:s. You can have as many lines as you want over a
> the same basebandconnection (up to 63 with one single multiplexer).
> MAX_NBR_OF_CONNECTIONS is however used to limit number of
> basebandconnections. But as you say it will probably be a
> waste of resources to have more than 7 lines at the same time.
> > > SDP shouldn't use a line at all as we are running the
> > SDP-server -> OpenBT
> > > communication through a procfile (in kernelmode). I guess
> > the line was
> > > intended to be used for a SDP-client
> > Yes, But it may have collision with RF_COMM which may get
> > same line and
> > the stack will not check for it.
> Yes I'm aware of this, I started to clean this up but haven't
> released it on sourceforge yet.
> > Although 'line' can/has to be used (in kernel mode)by SDP
> > client to get
> > SDP connection, you can't use it the same way as for RF_COMM
> > such as to
> > open /dev/ttyBTx (am I right here?). And I have no way to
> > disconnect it
> > (kernel mode again) once it has been connected. It seems to me that
> > it's remaining unfinished(SDP)--(I am using OpenBT 20010816 and I
> > checked its CVS site but no development on this issue).
> It's true that you can't use it in the same way as rf_conn right now. The
> problem is that we need functionality to receive sdp_data from the tty:s
> (currently bt_write_top sends the data to the rfcomm layer),
> but as I mentioned earlier this should really be handled by a socket and not
> mix it with the rfcomm-lines.
It should be even better if it's just not for SDP but as interface for
direct access to L2CAP of OpenBT.
>There is probably some more work to be done with
> the client parts of the stack. OpenBT was originally developed for use with
> our access point and therefore the functionality as a client stack isn't complete (yet) :).
> We probably need some more IOCTL:s to be able to, as example, disconnect a SDP-link.
> Currently BTDISCONNECT assumes that you have a line for the connection and this is
> only true for rfcomm-connections.
> > > but personally I think a socket
> > > is more suitable for this.
> > >
> > > Best Regards
> > > Anders Johansson
> > > -
Centre for Communications Research
University of Bristol
University Gate Tel: +44 117 915 1278
Park Row Fax: +44 117 954 5206
Bristol BS1 5UB
United Kingdom Email: Ran.Zhou@xxxxxxx.uk
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org