* Query regarding device discovery @ 2012-11-23 9:27 JAGANATH KANAKKASSERY 2012-11-23 9:54 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 4+ messages in thread From: JAGANATH KANAKKASSERY @ 2012-11-23 9:27 UTC (permalink / raw) To: linux-bluetooth SGVsbG8sIA0KIA0KSSBoYXZlIGEgZG91YnQgd2l0aCBjdXJyZW50IGRpc2NvdmVyeSBtZWNoYW5p c20uIA0KIA0KU3VwcG9zZSBhcHBsaWNhdGlvbiAxIGNhbGxzICJTdGFydERpc2NvdmVyeSIuIGZv ciB3aGljaCAiRGlzY292ZXJpbmcgPSBUUlVFIiBjb21lcw0KYW5kIHRoZW4gZGV2aWNlRm91bmQg c2lnbmFscyBzdGFydHMgY29taW5nLg0KSW4gdGhlIG1lYW4gdGltZSBhcHBsaWNhdGlvbiAyIGNh bGxzICJTdGFydERpc2NvdmVyeSIgd2hpY2ggd2lsbCBiZSBxdWV1ZWQgaW4gQmx1ZVouDQpUaGVu ICJkaXNjb3ZlcmluZyA9IEZBTFNFIiBjb21lcyBmb3IgdGhlIGRpc2NvdmVyeSBpbml0aWF0ZWQg ZnJvbSBhcHBsaWNhdGlvbiAxLg0KVGhlbiBhcyBwZXIgQmx1ZVogZGVzaWduLCBpdCB3aWxsIHJl c3RhcnQgZGlzY292ZXJ5IGZvciBhcHBsaWNhdGlvbiAxIHNpbmNlIGl0IGhhcyBub3QNCmNhbGxl ZCAiU3RvcERpc2NvdmVyeSIgeWV0LiBTbyAiZGlzY292ZXJpbmcgPSBUUlVFIiBjb21lcyBhZ2Fp biwgd2hpY2ggYXBwbGljYXRpb24gMg0KdGhpbmtzIHRoYXQgaXQgYmVsb25ncyB0byBoaW0uIA0K VGhlbiBpZiBhcHBsaWNhdGlvbiAxIGNhbGxzICJTdG9wRGlzY292ZXJ5IiBpbW1lZGlhdGVseSwg ZGlzY292ZXJ5IHdpbGwgYmUgc3RvcHBlZA0KYW5kICJEaXNjb3ZlcmluZyA9IEZBTFNFIiBjb21l cyB3aXRoIHdoaWNoIGFwcGxpY2F0aW9uIDIgdG9vIHRoaW5rcyB0aGF0IGRpc2NvdmVyeQ0KaW5p dGlhdGVkIGJ5IGhpbSBpcyBhbHNvIGRvbmUuDQpTbyBldmVudHVhbGx5IGFwcGxpY2F0aW9uIDIg d2lsbCBub3QgZ2V0IGFueSBkZXZpY2VzLg0KU28gSSB0aGluayB3aXRoIGN1cnJlbnQgZGVzaWdu LCBhcHBsaWNhdGlvbnMgdGhhdCBhcmUgaW50ZXJlc3RlZCBvbmx5IGluIG9uZSBjb21wbGV0ZQ0K aW5xdWlyeSBzZXNzaW9uIHdpbGwgYmUgaW4gdHJvdWJsZS4gDQogDQpTbyBjYW4gd2UgZGlzYWJs ZSB0aGUgYXV0b21hdGljIHJlaW5pdGlhdGluZyBvZiBkZXZpY2UgZGlzY292ZXJ5Pw0KT3IgaXMg dGhlcmUgYW55IHdheSB0byBoYW5kbGUgdGhpcyBzY2VuYXJpbz8gDQogDQpUaGFua3MsDQpKYWdh bmF0aA== ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Query regarding device discovery 2012-11-23 9:27 Query regarding device discovery JAGANATH KANAKKASSERY @ 2012-11-23 9:54 ` Luiz Augusto von Dentz 2012-11-23 13:24 ` Jaganath Kanakkassery 0 siblings, 1 reply; 4+ messages in thread From: Luiz Augusto von Dentz @ 2012-11-23 9:54 UTC (permalink / raw) To: Jaganath; +Cc: linux-bluetooth@vger.kernel.org Hi, On Fri, Nov 23, 2012 at 11:27 AM, JAGANATH KANAKKASSERY <jaganath.k@samsung.com> wrote: > Hello, > > I have a doubt with current discovery mechanism. > > Suppose application 1 calls "StartDiscovery". for which "Discovering = TRUE" comes > and then deviceFound signals starts coming. > In the mean time application 2 calls "StartDiscovery" which will be queued in BlueZ. > Then "discovering = FALSE" comes for the discovery initiated from application 1. > Then as per BlueZ design, it will restart discovery for application 1 since it has not > called "StopDiscovery" yet. So "discovering = TRUE" comes again, which application 2 > thinks that it belongs to him. > Then if application 1 calls "StopDiscovery" immediately, discovery will be stopped > and "Discovering = FALSE" comes with which application 2 too thinks that discovery > initiated by him is also done. > So eventually application 2 will not get any devices. > So I think with current design, applications that are interested only in one complete > inquiry session will be in trouble. > > So can we disable the automatic reinitiating of device discovery? > Or is there any way to handle this scenario? StartDiscovery doesn't queue the sessions, it actually increase the reference to the same discovery session which became shared between the callers, it should not interfere with the ongoing discovery nor change how we emit Discovering. That being said the concept of one shot inquiry is flawed since it can miss devices, with addition of LE this is even more visible because each inquiry is only 5.12 sec., you can still detect when an inquiry is active just check when Discovering is TRUE and nope it should not matter if there is 1 or 20 application listening to it once Discovery switch to TRUE we are inquiring/scan when it switch to FALSE it has stopped and is probably doing name resolving. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Query regarding device discovery 2012-11-23 9:54 ` Luiz Augusto von Dentz @ 2012-11-23 13:24 ` Jaganath Kanakkassery 2012-11-23 14:06 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 4+ messages in thread From: Jaganath Kanakkassery @ 2012-11-23 13:24 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth Hi Luiz, -------------------------------------------------- From: "Luiz Augusto von Dentz" <luiz.dentz@gmail.com> Sent: Friday, November 23, 2012 3:24 PM To: "Jaganath" <jaganath.k@samsung.com> Cc: <linux-bluetooth@vger.kernel.org> Subject: Re: Query regarding device discovery > Hi, > > On Fri, Nov 23, 2012 at 11:27 AM, JAGANATH KANAKKASSERY > <jaganath.k@samsung.com> wrote: >> Hello, >> >> I have a doubt with current discovery mechanism. >> >> Suppose application 1 calls "StartDiscovery". for which "Discovering = >> TRUE" comes >> and then deviceFound signals starts coming. >> In the mean time application 2 calls "StartDiscovery" which will be >> queued in BlueZ. >> Then "discovering = FALSE" comes for the discovery initiated from >> application 1. >> Then as per BlueZ design, it will restart discovery for application 1 >> since it has not >> called "StopDiscovery" yet. So "discovering = TRUE" comes again, which >> application 2 >> thinks that it belongs to him. >> Then if application 1 calls "StopDiscovery" immediately, discovery will >> be stopped >> and "Discovering = FALSE" comes with which application 2 too thinks that >> discovery >> initiated by him is also done. >> So eventually application 2 will not get any devices. >> So I think with current design, applications that are interested only in >> one complete >> inquiry session will be in trouble. >> >> So can we disable the automatic reinitiating of device discovery? >> Or is there any way to handle this scenario? > > > StartDiscovery doesn't queue the sessions, it actually increase the > reference to the same discovery session which became shared between > the callers, it should not interfere with the ongoing discovery nor > change how we emit Discovering. That being said the concept of one > shot inquiry is flawed since it can miss devices, with addition of LE > this is even more visible because each inquiry is only 5.12 sec., you > can still detect when an inquiry is active just check when Discovering > is TRUE and nope it should not matter if there is 1 or 20 application > listening to it once Discovery switch to TRUE we are inquiring/scan > when it switch to FALSE it has stopped and is probably doing name > resolving. With this concept even if inquiry is completed, Discovery = FALSE should not be sent. Because anyway BlueZ will start a new Discovery on its own. So application gets Discovery = FALSE and then immediately Discovery = TRUE. So I think until application calls "StopDiscovery", Discovery = FALSE should not be sent Thanks, Jaganath ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Query regarding device discovery 2012-11-23 13:24 ` Jaganath Kanakkassery @ 2012-11-23 14:06 ` Luiz Augusto von Dentz 0 siblings, 0 replies; 4+ messages in thread From: Luiz Augusto von Dentz @ 2012-11-23 14:06 UTC (permalink / raw) To: Jaganath Kanakkassery; +Cc: linux-bluetooth@vger.kernel.org Hi, On Fri, Nov 23, 2012 at 3:24 PM, Jaganath Kanakkassery <jaganath.k@samsung.com> wrote: > Hi Luiz, > > -------------------------------------------------- > From: "Luiz Augusto von Dentz" <luiz.dentz@gmail.com> > Sent: Friday, November 23, 2012 3:24 PM > To: "Jaganath" <jaganath.k@samsung.com> > Cc: <linux-bluetooth@vger.kernel.org> > Subject: Re: Query regarding device discovery > > >> Hi, >> >> On Fri, Nov 23, 2012 at 11:27 AM, JAGANATH KANAKKASSERY >> <jaganath.k@samsung.com> wrote: >>> >>> Hello, >>> >>> I have a doubt with current discovery mechanism. >>> >>> Suppose application 1 calls "StartDiscovery". for which "Discovering = >>> TRUE" comes >>> and then deviceFound signals starts coming. >>> In the mean time application 2 calls "StartDiscovery" which will be >>> queued in BlueZ. >>> Then "discovering = FALSE" comes for the discovery initiated from >>> application 1. >>> Then as per BlueZ design, it will restart discovery for application 1 >>> since it has not >>> called "StopDiscovery" yet. So "discovering = TRUE" comes again, which >>> application 2 >>> thinks that it belongs to him. >>> Then if application 1 calls "StopDiscovery" immediately, discovery will >>> be stopped >>> and "Discovering = FALSE" comes with which application 2 too thinks that >>> discovery >>> initiated by him is also done. >>> So eventually application 2 will not get any devices. >>> So I think with current design, applications that are interested only in >>> one complete >>> inquiry session will be in trouble. >>> >>> So can we disable the automatic reinitiating of device discovery? >>> Or is there any way to handle this scenario? >> >> >> >> StartDiscovery doesn't queue the sessions, it actually increase the >> reference to the same discovery session which became shared between >> the callers, it should not interfere with the ongoing discovery nor >> change how we emit Discovering. That being said the concept of one >> shot inquiry is flawed since it can miss devices, with addition of LE >> this is even more visible because each inquiry is only 5.12 sec., you >> can still detect when an inquiry is active just check when Discovering >> is TRUE and nope it should not matter if there is 1 or 20 application >> listening to it once Discovery switch to TRUE we are inquiring/scan >> when it switch to FALSE it has stopped and is probably doing name >> resolving. > > > With this concept even if inquiry is completed, Discovery = FALSE should not > be sent. Because anyway BlueZ will start a new Discovery on its own. > So application gets Discovery = FALSE and then immediately Discovery = TRUE. > So I think until application calls "StopDiscovery", Discovery = FALSE should > not be sent StartDiscovery processing with 3 instances is like this: StartDiscovery #1 org.bluez.Adapter.Discovering=TRUE Inquiry name resolving org.bluez.Adapter.Discovering=FALSE org.bluez.Adapter.Discovering=TRUE Inquiry name resolving org.bluez.Adapter.Discovering=FALSE StartDiscovery #2 org.bluez.Adapter.Discovering=TRUE Inquiry StartDiscovery #3 name resolving org.bluez.Adapter.Discovering=FALSE ... org.bluez.Adapter.Discovering=TRUE StopDiscovery #3 Inquiry StopDiscovery #2 StopDiscovery #1 org.bluez.Adapter.Discovering=FALSE So org.bluez.Adapter.Discovering=TRUE will track each individual round of the inquiry+name resolving, org.bluez.Adapter.Discovering=FALSE is there just to let you know when another round is about to start in case anyones cares about each individual round or want to do a single round of discovery. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-11-23 14:06 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-11-23 9:27 Query regarding device discovery JAGANATH KANAKKASSERY 2012-11-23 9:54 ` Luiz Augusto von Dentz 2012-11-23 13:24 ` Jaganath Kanakkassery 2012-11-23 14:06 ` Luiz Augusto von Dentz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox