Thread (6 messages) flat view 6 messages, 4 authors, 2011-06-30

Re: Generic Attribute API race condition

From: Claudio Takahasi <hidden>
Date: 2011-06-08 17:44:34

Hi Jaikumar,

On Wed, Jun 8, 2011 at 11:18 AM, Jaikumar Ganesh [off-list ref] wrote:
Hi Claudio:

On Tue, Jun 7, 2011 at 11:41 PM, Claudio Takahasi
[off-list ref] wrote:
quoted
Hi All,

There is a potential race condition in the Generic Attribute API. I'd
like to collect opinions to avoid re-work later.

How to reproduce:
- call CreateDevice() for a device which exports a GATT based service:
CreateDevice will discover all primary services
 and the Generic API will register the object paths for all found services
- Call DiscoverCharacteristics() of the primary service followed by
Characteristic GetProperties(), expected result: read all
characteristics properties outcome: partial characteristics properties
may appear.

This problem happens because DiscoverCharacteristics() doesn't wait
for all characteristic VALUES, it returns after discovering all
characteristic DECLARATIONS.
Wait for characteristic values is a problem, attributes may require
authentication or authorization.

Suggestions are:
1. Report discovered characteristic values using PropertyChanged:
Returning empty properties values (for GetProperties) if the discovery
is in progress

2. Block GetProperties() if there is a discovery pending: returning
after discovery finishes. Timeout can still happen!

3. Return Busy for GetProperties() if there is a characteristic
discovery in progress

Comments?
I don't think we should read characteristic value till the application
asks for it.
Are you suggesting to trigger the characteristic value and descriptors
read when Characteristic GetProperties() is called and block it?
Remember that GATT timeout is 30seconds and the default D-Bus message
reply timeout is smaller.
DiscoverCharacteristics() should just return after getting the DECLARATIONS.
This is current behaviour.
A client might not be interested in all the values and thus we should
read them only
when needed by the client. This will save both time and power and
solve this problem too.
I don't think it is critical, we are not reading them on all
connections/re-connections and the profiles available at the moment
don't expose "complex" characteristics.

BR,
Claudio
Thanks
Jaikumar
quoted
BR,
Claudio
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help