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

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

Received on Tuesday, 12 September 2017 07:57:16 UTC