BLE Host: enable per-connection storage of selected ATT attributes

[grochu]

Introduction: currently the only attribute which is tied with each BLE connection is CCC - due to its special function. However some GATT Services may require such per-connection storage for other attributes as well. Use case example: e.g. in HID over GATTS, the Protocol Mode attribute may be set differently by different connected peers (BLE HID Clients). They may use different Protocol Mode, so when a key is pressed on a keyboard, different reports (of different format) need to be sent to each peer. In general, any GATT Service which contains writable Characteristics (with or without response) and allows multiple connections, may need per-connection storage of these Characteristics. Idea: Extend a bt_conn structure in such a way, that application can register its context (in this case selected GATT attributes) to tie the context with a connection instance (for its lifetime).

[carlescufi]

cc @joerchan @jhedberg to avoid multiple assignment.

[Vudentz]

Im not sure it is worth it since bt_conn is reused so it only works for attributes that don't have to be persisted across connections. In any case the storage must come from the application/service anyway so I wonder if wouldn't be better to do something like CCC and define a special struct to store the user_data per peer, the stack would then check if that is in use and perform a lookup for the peer data before passing it as user_data to the application.

[grochu]

@Vudentz Maybe CCC was not the best example, as it is stored persistently for bonded peers. The use case we were thinking of, requires context registration just for the lifetime of a connection, not persistently for the lifetime of a bond - but this can be considered too. Any ideas what it could be used for? The persistent implementation would be slightly heavier - would require accesses to non-volatile storage. In a more generic form, our use case is: a device has a certain GATT Database, which is discoverable by multiple connected clients (the clients see the same attributes). But each client can set the writable characteristics to different values, e.g. changing sampling/measurement mode, data buffering scheme, can trigger action on the server via "control point" characteristics etc. This is important while in connection to provide "customized" service to each connected client. At this point I don't think these values must necessarily persist across connections. Are there GATT services/profiles which require persistent storage of selected writable attributes (other than CCC descriptor)?

[carlescufi]

@grochu @Vudentz to me it's still a bit unclear how best to solve this. Is a generic solution possible or do we simply want to have an additional user_data pointer associated to each bt_conn that one can retrieve and use?

[carlescufi]

cc @joerchan

[Vudentz]

@grochu do we still need this or has this been solved by other means?

[Vudentz]

Closing due to inactivity, fill free to reopen if there is any update.