How to find Device model number from unique device ID

One hint I have so far: Listen for DeviceIdentity data and cache that so that when you see a unique_device_id you can find the model etc. of the device that sent it.

Now my question is: what if my app is a late joiner and the device has already broadcast it's one-time-only DeviceIdentity? Is there a way to request a given unique_device_id to re-send its DeviceIdentity? I see this appearing when I start my late-joiner app, but today I suspect that the OpenICE Supervisor is cacheing that info for me - is that true? Or does the device adapter report the DeviceIdentity when a new Subscriber appears?

Thanks as always,
Brad

Hey Brad,

I believe that DeviceIdentity should be shared with late joiners by the DDS layer as part of the discovery process. I think of DDS as a hybrid discovery service and distributed cache. When a subscriber discovers and matches a publisher, it should read the other writer's current state information, including the DeviceIdentity. I'm not an expert with the intricacies of the DDS implementation however so I will confirm this answer and elaborate.

This is where I look for DDS documentation: http://community.rti.com/rti-doc/510/ndds/doc/html/api_c/group__DDSSubscriberExampleModule.html

Thanks,
Jeff

Jeff Peterson is absolutely right. I'll add further detail as well. For an overview of why the "HeartBeat" topic exists check this post out. For the existing OpenICE code that tracks HeartBeat, DeviceIdentity, and DeviceConnectivity please check out DeviceListModelImpl.

The DDS Writer/Reader construct is a type of distributed data cache (albeit with 'unique' APIs). When a writer and reader are matched (on topic name, partition, and QoS request/offer compatibility) the samples in the writer are synchronized with the reader. Controlled by QoS, the "Writer" is a collection and the "Reader" is a remote peer collection. By entering samples into a Writer you are expressing the desire that those samples make their way into all matched Readers. The paradigm is data-centric and not message oriented. Provided that a writer is configured to maintain a history of samples, transmit reliably, and maintain samples at least transiently then a "late joiner" will automatically receive extant samples when matched with a writer that already contains samples (OpenICE uses this type of QoS). Depending on your point of view you could call it "confusing" or maybe "flexible" that with different QoS settings (not the ones used in OpenICE) the same middleware becomes message-oriented.

Transient detachment from and reattachment to the network is a challenge. Specifically in this case
1.) Writer has synchronized all its samples to Reader
2.) Detachment -- Reader marks samples as NOT_ALIVE
3.) Re-attachment -- Writer and Reader verify that they are already at the *same* sequence number .. so no sample information is exchanged .. and samples remain in the "NOT_ALIVE" state
I would have thought in this case that existing samples would be re-marked ALIVE when liveliness is regained but it's underspecified in the standard and not implemented in this way by RTI (still within the bounds of the standard).

In theory, one approach could be to maintain a DeviceIdentity Reader and interrogate it on-demand for the most recent sample of a given instance. Populating a DeviceIdentity instance with only its keys (unique_device_identifier) would allow invocation of lookup_instance after which the returned InstanceHandle_t could be used in read_instance with max_samples of 1 to retrieve the most recent sample. I've never found this to be stable. And since auto-generated (from IDL) objects cannot be decorated for JavaFX anyway I'm already forced to maintain peer collections to my readers which I tend to use for this purpose. Maintaining all most recent samples without regard to liveliness. This is the strategy in DeviceListModelImpl.

I hope this helps.