https://www.oreilly.com/library/view/ge ... t_svc_disc
Additionally, CCCDs have two special properties that separate them from other attributes:
Their values are unique per connection
In multi-connection scenarios, in which a central is connected to multiple peripherals and also acting as a GATT server, each peripheral will receive its own copy of the CCCD’s value when reading it with ATT.
Their values are preserved across connections with bonded devices
“Attribute Caching” discusses attribute caching in more detail, but that concerns only attribute handles. Values are typically not stored per-device and the GATT server can reset them between connections. This is not the case with CCCDs among bonded devices: the last value written by a client to a CCCD on the server is guaranteed to be restored upon reconnection, regardless of the time elapsed between connections.
It says there must be a unique value for the peripherals from the central one. As I understand it, the central device should contain one instance of the descriptor for each connection. As you know, the central is the client. Do I understand correctly that the CCC descriptor must be at the client side? And how does the server know that the client wants notifications if the decryptor is at the client side?
That is, the mechanism is the same that I used in my implementation, with the only difference that I used a special characteristic, and I had to use the CCC descriptor for this. There I watched who writes to this special characteristic, saved the value of the id of the connection and started sending notifications on this connection. I am glad that I managed to practically guess the correct mechanism. But this is if CCC descriptor locate on the server side. If it is on the client side, then I do not understand how this can work.4) on connect you get connID/handle, which can be then used in read/write/notify/indicate operations to distinguish which client it is, the same handle you can use to track which client write to CCC and wants notifications