Hi Marcel, On 03/20/2013 06:10 PM, Marcel Holtmann wrote: > Hi Christian, > >> This is a follow-up on the discussion started in my patch set >> "MAP client: notification support". The patches were implementing >> notification support only for one remote device and needed an additional >> API function for choosing that device. >> >> It's better to implement this implicitly and support multiple devices >> from the beginning. >> >> In this E-Mail I'd like to suggest how we could implement the >> notification connection setup in BlueZ. I'll try to explain the relevant >> part of the spec to have a base for discussion. >> >> MAP consists of two different OBEX applications, Message Access Service >> (MAS) for browsing messages and Message Notification Service (MNS) for >> receiving event reports about changes on the server (like new messages, >> moved messages, delivery reports, ...). >> >> The spec describes the single phone use case where the MAP client (MCE) >> consists of several MAS client instances for the different accounts and >> one common MNS server instance: >> >> MCE (Car Kit) MSE (Phone) >> +---------------+ +-------------------------+ >> | MAS client 1 |<->| MAS server 1 (SMS) | >> | MAS client 2 |<->| MAS server 2 (E-Mail A) | >> | ... | | ... | >> | MNS server |<->| MNS client | >> +---------------+ +-------------------------+ >> >> Every MAS client instance, that wants to use notifications, needs to >> use the SetNotificationRegistration function to enable it. >> If the MNS connection isn't established already, the server (MSE) will >> start the SDP lookup for the MNS instance on the client and connect to >> it. The event reports that are sent on the MNS channel contain the MAS >> instance ID, that can be used to map the event to the MAS client. >> >> Since an OBEX instance, like the MNS server, cannot be connected to >> different remote devices at the same time, it will not work to have one >> static MNS server instance. Instead we need one MNS server instance for >> every connected remote device (that we want to use with MAP). Since the >> MNS connection establishment is based on SDP, we have to make sure that >> there's only one MNS server SDP record visible. Otherwise, the MSE >> cannot know which one to connect to. > > are you sure about this? In theory you could just use another OBEX connection id for the second connection. Has this actually been tested? > >> If we want to hide this all from the application level, we could do the >> connection establishment for two devices (MSE 1 and MSE 2) as described >> here. >> >> MCE (Car Kit) MSE 1 (Business phone) >> +---------------+ +-------------------------+ >> | MAS client 1 |<->| MAS server 1 (SMS) | >> | MAS client 2 |<->| MAS server 2 (E-Mail A) | >> | ... | | ... | >> | MNS server 1 |<->| MNS client | >> | | +-------------------------+ >> | | >> | | MSE 2 (private phone) >> | | +-------------------------+ >> | MAS client 3 |<->| MAS server 1 (SMS) | >> | ... | | ... | >> | MNS server 2 |<->| MNS client | >> +---------------+ +-------------------------+ >> >> - MCE connects MAS client 1 to MSE 1 >> - MCE dynamically instantiates MNS server 1 and registers its SDP record >> - MAS client 1 sends SetNotificationRegistration(on) >> - MSE does SDP lookup and connects to the found MNS server 1 >> - MCE removes SDP record for MNS server 1 >> - MCE connects MAS client 2 to MSE 1 >> - MAS client 2 sends SetNotificationRegistration(on) >> (MNS channel is already up, MSE just responds OK) >> - MCE connects MAS client 3 to MSE 2 >> - MCE dynamically instantiates MNS server 2 and registers its SDP record >> - MAS client 3 sends SetNotificationRegistration(on) >> - MSE does SDP lookup and connects to the found MNS server 2 >> - MCE removes SDP record for MNS server 2 >> ... >> >> Does that sound reasonable for you? > > This proposal is inherintly racy. I also do not understand it. When you have a different ACL link, then you can have the same RFCOMM channel established twice. So why are we bothering with this. > > If you are expecting one client connection from each MSE, then there is no need to play any of these tricks. And if a MSE wants to establish more than one client connection, then it is better able to use different connection ids. > > Regards > > Marcel I agree. As written in response to Luiz's Mail I have tested connecting two devices to one MNS instance a couple of weeks ago and I couldn't get it to work. Because of some misleading old mails, saying that it is possible only with L2CAP, I didn't pursue the simple approach. However, after your helpful hints, I have retested it and confirm that dual connections to the same MNS server instance works fine. This makes both, the proposal and a dedicated API call for setting up the notification connection obsolete. I will split up my patch set as requested into smaller parts and send it as different sets to simplify the review. Br, Christian -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
