Hi Chen Ganir, On Tue, Oct 25, 2011 at 10:19 AM, Ganir, Chen <chen.ganir@xxxxxx> wrote: > Claudio > >> -----Original Message----- >> From: Claudio Takahasi [mailto:claudio.takahasi@xxxxxxxxxxxxx] >> Sent: Tuesday, October 25, 2011 2:53 PM >> To: Ganir, Chen >> Cc: linux-bluetooth@xxxxxxxxxxxxxxx >> Subject: Re: GATT Dbus API on BlueZ >> >> Hi Chen Ganir, >> >> On Tue, Oct 25, 2011 at 4:38 AM, Ganir, Chen <chen.ganir@xxxxxx> wrote: >> > Hi. >> > >> > Currently, the DBUS API for GATT Client will allow discovering >> characteristics and services, connecting to the peer device if >> required. However, when the operation is done, the link is dropped (no >> more attio registered). The only way to register a global gatt_service- >> >attio and keep the connection alive all the time is to register a >> characteristic watcher. Is there another way to do it ? I'd like to >> keep the link a live (for example, implementing a proximity link loss >> profile on top of the DBUS GATT Client) without the need for a watcher. >> > >> > Thanks, >> > Chen Ganir >> > >> > >> >> At the moment there isn't another way to keep the link up. GATT >> Profiles have different connection requirements, you will need a >> dynamic mechanism anyway. The callback registration is the mechanism >> to inform the core that connection is required. If you keep the >> connection always up it will be necessary a function to get access to >> the GAttrib instance and a way to notify that the connection has been >> established. >> >> I tried to remove the association between GAttrib and GIOChannel. The >> idea was to create GAttrib even if the link is disconnected, but the >> effort doesn't worth. We will have problems with MTU and GATT >> abstractions for read long. >> >> Do have another suggestion to control connections and control the ATT >> request/response queue? >> >> BR, >> Claudio > > Thanks for the reply. > > However, I did not quite understand your response, nor the relevancy to read long. > > My basic requirement is to allow a profile to control the connection - meaning that if I implement a proximity or other profile over dbus, I would like to be able to tell it to connect, discover services, discover characteristics, poll from time to time the value of a certain GATT char, or simply idle and wait for disconnection (like proximity does) or notification/indication. When using dbus-send I end up with a disconnected link at the end of the process. Do you think the disconnection results from the termination of the dbus-send application, or is it something else ? > > Thanks, > Chen Ganir. > > You are disabling all the GATT plugins, so my suggestion is: open the ATT L2CAP socket directly in your JNI bindings. Using this approach you will have all the control that you need. We track the users/clients based on the D-Bus connection, if the client(dbus-send or any other) leaves the bus the core will disconnect link if watcher list is empty. BR, Claudio. -- 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
