Reading disk data is currently accomplished by redirecting the raw input stream
for the duration of the acquisition, during which no other operation can be
carried out. This change moves disk data reading into the packetizer so the
familiar request/reply with message filters can be used. To accomplish this the
deprecated ISOPIC network type was dropped because the two messages share this
network ID.
Also fixes live data packet lengths which were off-by-one.
Add support for live data subscription via Device::subscribeLiveData() and
Device::unsubscribeLiveData(). The live data API can be used to subscribe to
individual "signals", a full list of which can be found in LiveDataValueType.
This allows us to better implement alternative drivers
for devices, such as for device sharing servers or
talking to CoreMini processors within the same device.
The following fixups were added during the squash/merge:
Fix formatting in EthPhyMessage and EthPhyRegPacket
Device: Use std::make_shared when creating the EthPHYControl filter
Network: Create NetID String for EthPHYControl
EthPhyRegPacket: Constants in PascalCase
Because there is now more than one "product name" per device
type, we have a concept of a "generic product name" which
singularly maps onto a device type.
This change comes with a few small breaking changes within
the C++ API:
DeviceType::GetDeviceTypeString has been renamed to
DeviceType::GetGenericProductName to denote that
the returned value is not device specific and
device->getProductName() is preferable.
The member function DeviceType::toString has been renamed
to DeviceType::getGenericProductName for the same reason.
The DeviceType std::ostream& operator<< has been removed
to avoid accidental use of the generic product name.
This allows for disconnections to be detected quickly
where possible.
It also makes sure other driver errors aren't thrown
in the event of a disconnection.
When a device is sending any traffic, the device is considered to be connected. If no traffic if being received from the device, a status is requested. If the device fails to report the status back in a timely manner, it is considered to be disconnected.
If the device fails to reply to the status request, it is important to confirm that the device is not applying settings. While the device is applying settings, it will not be sending heartbeats or able to process a status request.
This also makes it possible for Communication to create more instances of Packetizer
This is necessary because Packetizer is not thread safe,
so when we support more VNETs we will need to create more Packetizers.
Kyle Schwarz
Kyle Johannes
Yasser Yassine
Jonathan Schwartz
Joseph Niksa
Emily Brooks
Yasser Yassine
Paul Hollinsky
EricLiu2000