Infrastructure: Input/Output Device System - [merged]

[benloh]

In GitLab by @daveseah on Apr 16, 2021, 20:35

Merges feat/io-systems-4 -> dev

The Input and Device Management System is now available for integration. The system has several features to avoid problems we've had with synchronizing applications in the past while also anticipating our upcoming needs in GEMSTEP.

** THE LATEST DEV BRANCH ** has been merged-in to this branch

OVERVIEW OF KEY OPERATIONS

The major design goal for the Input and Device System was to provide a single getInputs() function "just knew how" to deliver a bunch of data objects, each with a unique id, as an array of values. This follows our very earliest simulation loop conventions, so theoretically it's easy to add as a drop-in replacement.

In practice, there are two main activities you'll do: (1) defining and registering a device from any webapp, and (2) subscribing to a set of devices with desired properties.

Creation

• Create a UDevice and attach input and output definitions. Each device can have multiple named inputs and outputs each with their own control object format. The names and encodings of all named controls are stored in the device definition for optional future data validation or processing.

• Registering a UDevice makes it available across the network through the self-syncing device directory

Subscription

• Subscribe to sets of devices by providing a subscription specification where you dictate types and quantity of devices through pluggable functions. You can optionally be notified through a callback when your subscription criteria become valid or invalid.

• A subscription provides a deviceAPI that can prove a controller through which you can (1) specify the name of the control you want from the devices in the subscription spec and (2) retrieve all current entities through one getInputs() call that returns either a set of added, updated, removed objects or all objects. This is the pattern we've used in STEP so it should be familiar.

Other Nice Things

You can define multiple devices on the same webapp to group controls together.

Likewise you can subscribe to multiple subscription specs, each with its own "controller object" that you can manage whatever way you want.

The underlying systems takes care of all synchronization and communication between device subscribers and creators so it is easy to know if a particular device or set of devices are available.

Any device can belong to multiple subscriptions, with all control data buffered in independent caches. Control data is rewritten in each subscription to have a unique id based on its originating device. This ensures that multiple devices of the same type no longer produce id collisions.

The working reference implementation:

• CharControl is the character controller based on FakeTrack's UI. Instead of using the old PTRACK protocol, CharControl uses the device system to register itself as a "CharControl" device.

• Tracker now subscribes to all instances of the CharControl device class. While the UI is not currently plotting sprites in the renderer view, it does echo the current deviceList and controlData arriving from each of them in aggregate.

TO TEST

• pull the dsri/io-systems-4 branch
• in a terminal cd gsgo
• remember to npm ci and npm run boostrap!!!
• npm run gem to start server
• in chrome, open two windows and browse to localhost
• in first window open the CharControl app
• in second window open the Tracker app

Tracker Features

• There is a device list that updates as you add, remove, and reload instances of CharControl
• There is a device entity list that shows the ids and x,y values of each entity sent from a CharControl
• Note that device entities are not drawn as graphics in this release. This will come when we're able to acquaint the UI team with the new system and vice versa.

CharControl Features

• As before, you can set the number of entities.
• You can create multiple CharControl browser instances and they will all appear in the Tracker interface
• The control range has not been calibrated to Tracker; this will require a second pass on the graphic engine to establish our location-based coordinate system.

OTHER NOTES

We have implemented the minimum number of features to make a multi-instance CharacterController that tries to reduce the finicky app synchronization problems from the past.

As a bonus, the device system give us a more granular way of addressing applications compared to our generalized message system which is more suitable for broadcast than point-to-point.

We have also sketched-in placeholder properties in the device specification for application and user authentication, grouping, and tagging.

The device input management system is part of URSYS, so it is portable to other applications.

The communications system is currently using URSYS messaging instead of a dedicated socket communication channel. Socket channel management is a future feature to allow multiple servers to run on the same network and hosts without conflicting with each other.

We have several new interesting classes:

• DifferenceCache implements a 'collection differencer' that determines what has changed between two sets of objects with a common identify key. It can operate in both an immediate mode (great for managing complete sets of data) and in a buffered mode (necessary to handle partial data updates that occur over several frames). The updated, added, and removed sets of object are available as arrays.

• PathedHash implements a multi-level map with a path key of the form key1.key2.prop. This is an error-prone pain in the butt to code manually each time.

• UDevice is our representation of a device on the network. They all have network-wide unique ids called a udid, and it's based on the hosting webapp's URSYS address number (uaddr). It can serialize/deserialize itself from JSON object data so it can be sent over the network and reconstructed on the other side. Currently it is only used to generate "device descriptors" that are used for spreading the device directory, but it defines a lot of other properties that are useful for both application grouping and student identification for when we need them.

• client-netdevices is the URSYS module that implements the entire device protocol, handling automatic device directory discovery and subscription checking as devices are added/removed from the net. It works closely with client-datacore to manage subscriptions and device mapping.

For an overview of all the data structures in the system, see https://whimsical.com/input-system-dr01-Y2xuF7r1N1kxNJ2MyfzqZY@2Ux7TurymMHkbcce8GSq.

[benloh]

In GitLab by @daveseah on Apr 16, 2021, 21:08

added 192 commits

• ef4488c9...59c9f47e - 191 commits from branch dev
• e54d03f8 - Merge branch 'dev' into feat/io-systems-4

Compare with previous version

[benloh]

In GitLab by @daveseah on Apr 16, 2021, 21:09

marked this merge request as ready

[benloh]

In GitLab by @daveseah on Apr 16, 2021, 21:18

added 1 commit

• 9335b869 - io-systems-4: removed obsolete RegisterDevice() call from FakeTrack,

Compare with previous version

[benloh]

Huzzah!

[benloh]

mentioned in commit 62a5309ad10d954b541acc483844c0010838af71

[benloh]

In GitLab by @daveseah on Jul 14, 2021, 07:53

added 101h of time spent

[benloh]

In GitLab by @daveseah on Jul 14, 2021, 07:53

remove discount/unbilled hours

[benloh]

In GitLab by @daveseah on Jul 14, 2021, 07:53

subtracted 20h of time spent