[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 
<anders.t.johansson@xxxxxxx.com> wrote:

> > 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.

Thanks Anders

Ran
>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
> > > -
> 
> /Anders 

----------------------
Ran Zhou
Centre for Communications Research
University of Bristol
c/o: PACT
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 majordomo@xxxxxxx.com