[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 17:44:03 +0100  Anders_Torbjörn_Johansson 
<anders.t.johansson@xxxxxxx.com> wrote:

> Hello Ran,
> 
> 
> > a litter doubt about this. 63 is max channels for RF_comm connection
> > for each line. 
> 
> Well, one line = one DLCI. The current implementation doesn't work as it
> should. The main problem is that we have assigned the line for ONE
> rfcomm session (multiplexer), it should really be assigned in the DLCI object.
> This mean that we can't have multiple lines in the same multiplexer.
> Some months ago I redesigned the rfcomm layer but unfourtanly I didn't
> released it and now there is a lot of other changed which means that
> the merge will take some time :(. The line is assigned when a client
> connects (when we got connect_ind from the l2cap layer) and if the
> client then try to send another SABM message for another DLCI the 
> later one will not get a line on the serverside. This is behaviour
> is fine when running an accesspoint which only use one of the DLCI:s
> and as a result only one of the lines but other applications maybe
> need to connect multiple lines between the units. 
> 
> I saw some earlier posts about problems with running multiple
> DLCI:s between two units. When you are using rf_conn it should
> be no problem as each rf_conn command will result in another
> l2cap channel and therefore a new multiplexer (we are only
> running one line / multiplexer). But if you use another stack
> which are using the same l2cap and rfcomm session to connect
> another DLCI (which is the correct behaviour) we probably have 
> a potential problem as we already
> set the first line for the first DLCI and calling bt_register_rfcomm
> in bluetooth.c will result in a line busy (as the line is set in the
> multiplexer object and not in the DLCI).
> 
> I'll see if I have some spare time to merge the new code later 
> this week.
Hi, Anders
Is't possible to put SDP disconnection functinality first.

Many Thanks

Ran
> By the way I saw in the specs that we can only
> have up to 60 open emulated ports (62, 63 reserved) :).
> 
> > > 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.
> > > 
> > It will cause another collision here if you set 
> > MAX_NBR_CONNECTIONS > 7
> > because we just got 7 ttyBTX devices.
> 
> True :) and there is no hardware that supports more than 7 slaves either ;).
> I saw that we don't send a proper reply when we running out of lines either.
> Just a comment: fixme :).
> 
> Best Regards
> Anders Johansson
>  
> 
> -
> To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
> the body of a message to majordomo@xxxxxxx.com

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