As is shown in the figure above the VISS interface is well suited to serve clients deployed in different environments:
The payloads handled by the clients at any of these deployments are identical.
The MQTT transport protocol option, with the broker deployed in the cloud, is well suited for the client cloud deployment as the communication can traverse across subnets. The thin application layer protocol on top of MQTT that VISS defines makes it possible to keep the client-server communication, and payload compatibility.
There are a number of different clients avaliable on this repo, mainly in the client/client-1.0 directory.
The gRPC implementation uses the protobuf encoding in the VISSv2messages.proto file found here. The server currently only supports the protobuf level 1 encoding.
The MQTT client implements the application level protocol described in the specification.
The CSV client is developed for testing the curve logging algorithm that Geotab has opened for public cuse. A client can equest it to be aplied to data by using a filter option.
It generates a comma separated (CSV) file in which it saves the curve logged data that it has reuested from the server. The CSV format makes it easy to import it into an Excel sheet and visualize it as a graph which allows it e. g. to be compared with the original, non-curved data.
This client exercises the file transfer support by the VISSR server which supports it on the Websocket protocol. The CLI command enables it to be started for either upload or download, in which case a small text file is transported(upload.txt and dlFile.txt respectively). For this to work the binary tree must contain upload and download nodes which the vss_filetransfer.binary tree has been augmented with (the rest is VSS v5.0).
The compression client can be used for testing three payload compression variants.
This compression variant builds on a proprietary algorithm that takes advantage of knowing the VISSv2 payload format. Due to its strong dependence on the payload format it might require rewrites if/when the payload format is updated. It is not kept up to date on this and is therefore likely to crash if an unsupported payload is applied.
The encoding uses the VISSv2messages.proto file found here. The server supports this only for the Websocket protocol, where the websocket transport manager encodes payloads before sending them, and decodes payloads directly after receiving them. The client follows the same encoding/decoding behavior, so that the use of protobuf encoding is abstracted before other layers in both the server and the client get access to the payloads. Two levels of protobuf encoding are available, level one in which paths and timestamps have the standardized text format, and level two where these fields are compressed.
Level 2 compresses the VSS paths by using the VSS path list as a lookup table. Instead of using the string paths in the encoded payload the index into the array is used. Finding the index in the array for a given path is done by applying a binary search, as the array paths are sorted by the server. Going the other way, the array is simply indexed by the integer value from the protobuf encoded payload. The string based timestamps are replaced by an int32 as shown in the CompressTS() procedure found in computils.go. Level 2 achieves compression rates of around 5 or better.
There are a few clients that are written in Javascript, and thus when started opens in a browser. Thes clients can be quite handy for quick testing of the server functionality. Example payloads that can be used as input are found in the appclient_commands.txt file.
The HTTP Client requires the server IP address/URL to be written into the field for it, and the IP address button to be pushed. Thereafter paths can be written into the Get field, followed by a push of the Get button. In the case of the client writing a value to the server, the path is written into the Set field, with the value in the following field, before pushing the Post button. If the data associated with the path is access controlled, then the access token that must have been obtained via the dialogues with the two autorization servers must first be written into the field for the token. Klicking the button to the right of it preserves the token for use in multple requests.
The Websocket Client requires the server IP address/URL to be written into the field for it, and the IP address button to be pushed. Thereafter JSON based payloads can be written into the Sed field, followed by a push of the Send button.
The Websocket Client requires the server IP address/URL to be written into the field for it, and the IP address button to be pushed. Thereafter JSON based payloads can be written into the Sed field, followed by a push of the Send button. The difference to the uncompressed Websocket client is that this client opens a Websocket session with the erver in which it requests a session in which proprietary compression is applied to the payloads (see chapter above).
The AGT client requests an Access Grant Token from the Access Grant Token server.
It requires the AGT server IP address/URL to be written into the field for it, and the Server IP button to be pushed. In the leftmost field below “agtserver” (no quotes) must be written, then in the rightmost field a request payload shall be written. A payload example can be found in the appclient_commands.txt file. The proof value must be “ABC” for a positive validation, in which case an Access Grant token is returned.
The AT client requests an Access Token from the Access Token server.
It requires the AT server IP address/URL to be written into the field for it, and the Server IP button to be pushed. In the leftmost field below “atserver” (no quotes) must be written, then in the rightmost field a request payload shall be written. A payload example can be found in the appclient_commands.txt file. The token that is provided in the request must include an Access Grant token from the response of a successful reuquest to the AGT server.
The client/android/covesa-vissr-app-demo directory contains an Android app that realizes a VISSv2.0 client. This was demoed at the COVESA spring 2024 AMM in Gothenburg. Presentation, Demo recording
The VISS web client exposes a sophisticated UI that includes support for the dialogues that a client needs to have with the authorization server in scenarios where access control is required.
The CCS client uses either HTTP (for Get requests), or Websocket (for subscribe requests) to access data according to a list of paths in a config file, and then requesting an OVDS server to write this data into the OVDS database.
The CCS MQTT client uses the VISSv2 MQTT based protocol to subscribe to data according to a list of paths in a config file, and then requesting an OVDS server to write this data into the OVDS database.