...
The sequence diagram below in figure 3 2 illustrates the typical sequence of events when an end-user’s application uses the SDK to retrieve data from a VictoR device. In this example, the end-user makes a call to the Device Information Service to retrieve the Firmware Revision. This function has knowledge of which particular attribute ID this data corresponds to, and uses that information along with the provided device ID (if provided - otherwise it uses the Current Device ID) to call into the Base Service. The Base Service uses the Device Manager to request a read of the specified attribute from the specified device ID. The Device Manager takes that request, looks up the matching Device Interface from its internal map of devices, and forwards the request to that device. The Device Interface in turn requests a read of the specified attribute from a VictoR Device over the underlying communications protocol (which is determined by the particular Device Interface that was constructed). This sequence of function calls is non-blocking, so that the end-user is not left blocked waiting for the device to respond with the data. Once the device has finished processing the request and the data has been successfully transmitted back to the Device Interface, it is propagated back down to the Device Information Service in its serialized binary form. The original function used to retrieve the Firmware Revision contains logic to deserialize the the Firmware Revision from its binary form into an ordered Firmware Revision data structure that is then finally returned to the end-user.
...