c# - In BLE GATT profile are characterstics really being read or written?

Question

According to the specification of BLE GATT profile characteristics are the smallest unit of data that can be exchanged between a GATT server or client. A GATT client can request to read or write to the value of characteristics under a service on a GATT server. But in most of the implementations of GATT I've seen till now (Windows and Android) there are event handlers for the characteristics on the server side for events such as ReadRequested or WriteRequested events which are triggered when a client requests a Read or Write on that characteristic. In the event handlers we can send a response with whatever we want (characteristics don't hold any data others than its UUID or its properties). In case of Write request the server receives the data from client and choose to do whatever it wants with it the characteristic is never changed. The characteristics are not technically being read from or written to. My question is why the original concept of characteristics being read from or written to not used?
PS: Here I've attached the link of how to create GATT Server and Client in UWP application.
Server: https://docs.microsoft.com/en-us/windows/uwp/devices-sensors/gatt-server
Client:https://docs.microsoft.com/en-us/windows/uwp/devices-sensors/gatt-client

question from:https://stackoverflow.com/questions/65944483/in-ble-gatt-profile-are-characterstics-really-being-read-or-written

Answer 1

It's just terminology. You could call it "receive"/"send" to yourself instead of "read"/"write" if you think that's better.

The original idea is that the value should be attached to the characteristic and simply read/written by the client directly. Or updated by the server followed by a "notification" containing the new value to the client (for example for a temperature sensor).

But this model is not enough for all profiles. For example, firmware updates do not fit well within this model. Neither does HID. So it's allowed to just use the characteristics as a way of transferring data. It's up to each profile to define how to handle reads and writes for the characteristics. For example, the "Name" and "Appearance" characteristics in the GAP service usually returns a constant value, which might stored in the characteristic object. But for HID we have "control point" characteristics where values are actually not stored anywhere.

I have seen these API variants for defining characteristics for different Bluetooth stacks:

1. Embed the characteristic value in the characteristic object and let the Bluetooth stack handle reads/writes internally.
2. Don't embed any characteristic value but expose read/write handlers.
3. Reserve some space in the characteristic object for the value, but have read/write handlers that can process the data before/after writing/reading the characteristic value from the storage.

Option 2 is the most flexible, and is used with for example Android's app-implemented gatt services.