Re: Standardized endpoint name for VISS (was: Re: Request to make the issue list for VISS)

Hi Gunnar,

Thanks, you raise and make some very pertinent points.

Suggest that another important point is:  What if an OEM wants to install
two or more VIS Servers on the same vehicle network.

For example, the designers of the instrument cluster might decide to
implement the VISS specification and install a VIS Server in the cluster in
order to get vehicle speed, engine rpm, fuel levels etc and display them to
the user.

Almost in parallel, the designers of the new Infotainment System decide to
implement the VISS specification and add a VIS Server to the electronic
control unit (ECU) that hosts the Infotainment System.

Does anyone on the thread have views on how best to address this - or
should we remove references to wwwivi and state that implementors will
document how to connect to the VIS Server

Regards,

Kev


*Kevin Gavigan BSc, MSc, PhD, MCP, MCTS*
*Software Architect*
*Connected Infotainment*
*Electrical, Electronic and Software Engineering (EESE)*
Jaguar Land Rover


*Mobile: 07990 084866*
*Email:* kgavigan@jaguarlandrover.com

*Office address:*
GO03/057 • Building 523, Gaydon • Maildrop: (G03)
Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR

On 12 September 2017 at 08:56, Gunnar Andersson <gandersson@genivi.org>
wrote:

>
> I made a subject change - figured it should be more descriptive.
>
> On Thu, 2017-09-07 at 10:44 +0100, Gavigan, Kevin wrote:
> > Hi Gunnar,
> >
> > Thanks very much for asking re. this issue.
> >
> > The issue that the wwwivi name was trying to address was to provide a
> > standarized local endpoint name on the vehicle that would be the same
> > regardless of vehicle manufacturer.
>
> You're saying local, so would it be implied by this standard that it is
> indeed always running locally?  How local is it?  Could the apps just
> assume
> a loopback address, 127.0.0.1 (::1 or whatever it is on IPv6).
>
> Or might it be routed to a nearby "computer"?   That could of course be
> anything these days, (and I'm inclined to say the chosen solution should
> not
> sacrifice genericity for simplicity too much)
>
> - another ECU just on the other side of an Ethernet cable
> - a nearby sibling CPU in the same box - for example it's not unlikely to
> have a  dedicated CPU speaking to the Vehicle Bus connection.
> - another slice on a hypervisor,
> - or even a "container" on the same Linux kernel.
>
> Even within one Linux instance only, the IP address could be anything that
> you have configured a network interface to, of which you can have any
> number
> of virtual networks in a modern OS.
>
> >
> > This would mean that client Apps could be downloaded to vehicles created
> > by different manufacturers and connect to the VIS Server on those
> vehicles
> > without additional configuration being required.
>
> OK, that's what I thought, more or less.
>
> >
> > We were trying to avoid adding a dependency on a discovery service. We
> > could avoid the issue, by stating that the implementer of the server will
> > document how to connect to it.
>
> Agreed, that's the alternative of course.  Let me pick this apart a bit
> further.
>
> If we dig one level below the app-to-server connection.  In a typical
> standard system, I suppose that name resolution occurs, either through a
> Domain Name System server, or some static mapping that overrides it
> (/etc/hosts if it's a Unix system).
>
> When you speak of avoiding a discovery service, do we still think we need a
> name resolution to happen, provided by the operating system?   How does the
> connection from the Browser to the data server happen if not by actual IP
> address, IPv4 or IPv6?  It can't actually happen "by name", can it - there
> needs to be name resolution?
>
> I started wondering if a Websocket connection is special in this respect -
> that it could use an actual descriptive name or such.  But from what I can
> tell, it's not.  You need to send a request to an HTTP server and an
> "upgrade" command, agreed?   So when we get down to it, the first
> connection
> is still a networking socket being opened on port 80 or 443 (unless the URL
> specifies a custom port, naturally) to connect to the "server" on a
> particular IP address, right?  That address could be 127.0.0.1, but still
> an
> IP address that the networking subsystem will /route/ to the right
> machine.
> Or is there any magic there that I am missing?
>
> It seems the problem (solution?) you describe must then lie within the name
> resolution (domain to IP address translation), or have I missed something
> so
> far?  If we agree so far, we should be able to draw conclusions and decide
> from there.
>
> > As a group, we are keen to resolve this issue in the best way we can, so
> > will be grateful for your input.
>
> Doing my best!
>
> --
> Gunnar Andersson <gandersson@genivi.org>
> Development Lead
> GENIVI Alliance
>
>
> >
> > Thanks and regards,
> >
> > Kev
> >
> > Kevin Gavigan BSc, MSc, PhD, MCP, MCTS
> > Software Architect
> > Connected Infotainment
> > Electrical, Electronic and Software Engineering (EESE)
> > Jaguar Land Rover
> >
> > Mobile: 07990 084866
> > Email: kgavigan@jaguarlandrover.com
> >
> > Office address:
> > GO03/057 • Building 523, Gaydon • Maildrop: (G03)
> > Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR
> >
> > On 7 September 2017 at 09:50, Gun
>