[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
> 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.
Is't possible to put SDP disconnection functinality first.
> 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 firstname.lastname@example.org
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 email@example.com