[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] Line collision between SDP and RF_COMM






>From: Matthias Fuchs <matthias.fuchs@xxxxxxx.com>
>To: Bluetooth-dev <bluetooth-dev@xxxxxxx.com>
>Subject: Re: [bluetooth-dev] Line collision between SDP and RF_COMM
>Date: Wed, 30 Jan 2002 11:15:40 +0100
>
>Hi Ran Thou,
>
>you are right, I noticed the second problem some timeago.
>
>I have an application where two rfcomm data channels are needed:
>
>Device A connects to device B through rfcomm for LAN access. Further Device 
>A needs
>a rfcomm connection to device B for a special custom application that 
>relies on a transparent
>serial connection (no TCP/IP/PPP). It is not possible to setup these two 
>connections
>at the same time. I am not sure what happens if SDP is also connected at 
>the same time.
>
>Should we allow such scenarios ?

Certainly we should allow for these scenarios, if possible. What Ran 
describes seems more a problem of OpenBT implementation (maintaining 
resource allocation tables across different modules, such as SDP and RFCOMM) 
rather than conceptual. The scenario when a device starts with an SDP 
connection for query, and another request for connection comes in from 
another device pursuing a previous session is quite possible in environments 
beyond simple cable replacement scenarios - nothing should stop this RFCOMM 
connection to be set up concurrently with SDP (if there are Bluetooth 
"lines" available)

Or is OpenBT just for managing p2p-over-RFCOMM/PPP/IP connections?

Dritan

>Matthias
>
>Ran Zhou wrote:
>
>>Hi,
>>OpenBT(I am currently using OpenBT-20010816) uses 'line' for sdp
>>connection object and rf_comm connection object, this may cause
>>trouble for application.For example:
>>1. If device A opened connection to device B, A would get line0 for
>>    the connection. Then if B opened a rf_comm connection to A, the
>>    stack in A would assign line0 to the rf_comm connection unawaring
>>    that the line had already assigned to sdp connection. The application
>>    in A would have no way to use ioctl command 'BTISLOWERCONNECTED' to
>>    detect the rf_comm connection and can't open /dev/ttyBT0.
>>2. There is possibility (I guess OpenBT doesn't want this happens)
>>    that the A can have more than one 'line'  connecting to B(eg. one
>>    for rf_comm, one for sdp). This will cause problem too if you use
>>    'BTREADREMOTEBDADDR'.
>>These are just my experience, someone may correct me if I am wrong.
>>
>>Regards
>>
>>Ran
>>
>>----------------------
>>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
>>
>>
>>
>>
>
>
>--
>-------------------------------------------------------------------------
>
>                             _/_/_/_/   Matthias Fuchs
>                            _/_/_/_/   Dipl.-Ing.
>                           _/_/_/_/   matthias.fuchs@xxxxxxx.com
>
>       _/_/_/   _/_/_/_/_/_/_/      esd electronic system design gmbh
>     _/   _/  _/             _/    Vahrenwalder Str. 207
>    _/   _/    _/_/_/   _/   _/   D-30165 Hannover
>    _/             _/  _/   _/   Phone: +49-511-37298-0
>     _/_/_/_/_/_/_/   _/_/_/    Fax:   +49-511-37298-68
>
>-------------------------------------------------------------------------
>
>-
>To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
>the body of a message to majordomo@xxxxxxx.com




_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com