Meeting minutes
[VSS/VSSo call running over]
CVII summit on Thursday
Ted gives high level summary of agenda
VISSv2 over MQTT proposal
Ulf: we have been giving thought about how we can operate on both end of broker
[Ulf shares screen, presents diagram]
Ulf: in this diagram we have a client in vehicle and other external
… currently in the code we have transport managers for WS and HTTP, they register into the server core
… they open up data channel (WS, all of them)
… so it was easy to implement a new transport manager and get it to communicate
… we got quite a bit for free
… this vehicle client is a tranport manager to prove concept works
… MQTT starts with issuance of token request. a unique identifier is needed, currently using vin but may be better as something else
… we have a cloud client that knows it wants to send VISSv2 requests to server on the other side, starts subscribing to a uuid
… next it does a publish to topic it subscribed to. vinXX cannot be found in a session, needs to be transmitted out of band
… it could originate from oem backend
… payload is two parts. information about domain of the topic and actual request it wants to send
… it is a JSON payload
… topic and request parts. v2 valid payload is sent via WS
MQTT
flow diagram
… topic and request parts are forwarded to server which views it as any normal request
… it gets, processes and returns response
… response is published back, topic is in the payload. broker then pushes it back to subscribed cloud client
… this can support the entire range of requests available in v2
… so the experiment works, question is do we want to put this in the transport document
Ted wonders how much Peter (regrets for today) was involved as he knows MQTT better than I
Ulf: he was partially involved
… one thing we benefit from is client broker
… open question about security aspects of using a broker
Gunnar: connection starts on vehicle side
… not sure if it is crazy or genius
Ted: its a fine line...
Gunnar: did you implement the vehicle client as a separate process or part of the server?
Ulf: it is its own program running
… based on the HTTP code
Gunnar: instead of a client, it would be better termed as a proxy
… you are embedding VISS over MQTT more than using MQTT
Ulf: correct
Ted wonders if anyone else on the call has extensive experience with MQTT, this can be architected a number of ways
… we did want VISS consistent across protocols and this experiment achieves that
Adnan: MQTT is being used by a number of companies, we are
… what would be interesting to see is the split between the read and write parts
… you may want to split based on topics as well
… topic per client on reading. for write you could have one
Ulf: I need some more understanding
MagnusG: I haven't used MQTT myself. interesting concept being able to pair clients through a broker
… proxying or rather embedding VISS within MQTT is interesting
… nice to see how we are not tied to any particular protocol
Ulf: maybe we should take a week or two to reflect and discuss further
Glenn: would this affect the data payload size?
Ulf: slightly, the topic part adds a bit
… what is new is [on diagram] this small part
Gunnar: there may be room for more optimizations
Ted: I'll put a call out along with the minutes asking for expertise on MQTT
Issue review
Ulf: I have pushed some changes and already accidentally merged based on the editorial suggestions
… hopefully nobody objects, otherwise I would have to back it out
… please give it a read or wait until further changes
https://
Ted: service discovery moved?
Ulf: folded into filtering
https://
Ulf: what is taking more time is linking to definitions
Ted: hold on, that may be facilitated with some ReSpec capabilities