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

Hi Kevin,

 

I totally agree with a) you mentioned. I’d like to put it as a basic premise.

 

However, I’m not sure we should consider the multiple VIS servers on local network. As I understood, there are multiple VIS servers in the same local network and we’d like to connect to the server using a special host name like ‘wwwivi’. If right, it would be strange that two or more VIS servers can’t be operated at the same time.

 

When a server operates well, it gets an assigned IP address as an entry point so that clients can connect to the server. If someone tries to execute a server using specific IP address and port while the IP address and port are already used in existing server to receive a request through ‘wwwivi’, it will fail. The reason of failure is that ‘wwwivi’ will eventually  be resolved to the specific IP address and port to connect to VIS server, and to do so, the VIS server should be run with the IP address and port to be connected from the client using ‘wwwivi’. What I want to say is that the multiple VIS servers with same IP address and port can’t execute at the same time.

 

I agree that OEM want to use the multiple VIS servers on the same vehicle network. To support this case, there would be several bypass ways like using redirected(301 in case of HTTP), assigning dedicated port area, and selecting default VIS server through a communication between VIS servers. I guess Gunnar seem to consider one of these candidates in the mail below. If we define the special host name properly in our standard scope, OEM will be able to use it for their requirements without any problems at least on the multiple server issues.

 

Thanks,

Hyojin

 

From: Gavigan, Kevin [mailto:kgavigan@jaguarlandrover.com] 
Sent: Tuesday, September 12, 2017 7:51 PM
To: Gunnar Andersson
Cc: 이원석; Crofts, Adam; public-automotive
Subject: Re: Standardized endpoint name for VISS (was: Re: Request to make the issue list for VISS)

 

Hi Gunnar,

 

I have to be careful not to overstate what I understand to be the groups agreed intentions are based on what was discussed.

 

I'm not sure that I could go much further than make the following statement:

 

a) Because a vehicle will not typically have an IP address on the public internet until it is assigned a dynamic one, e.g. by the MNO and because this IP address could change e.g. as vehicle loses connectivity for a period, and re-establishes it, our view was that the VIS Server should be accessible from in-vehicle clients and we would not try to solve the problem of providing reliable access from the public internet.

 

b) A vehicle network should be able to support multiple VIS Servers on that network.

 

If anyone on the thread disagrees or would re-express the above, I would be grateful if you would correct me.

 

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 <mailto: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 09:46, Gunnar Andersson <gandersson@genivi.org <mailto:gandersson@genivi.org> > wrote:


On Tue, 2017-09-12 at 09:23 +0100, Gavigan, Kevin wrote:
> Hi Gunnar,
>
> Thanks, you raise and make some very pertinent points.

OK, good.  I was hoping someone would go through each of them and just
confirm that what I said was true, so far.  Because this is a process to
lead to a conclusion.  But I suppose maybe you agreed now, implicitly?

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

Yes even name resolution of a single well known name would not solve that.
You'd have to either have a discovery protocol of some sort (and then
zeroconf comes to mind -- yes I now saw the feedback Ted relayed, mentioning
mDNS, which is the same thing IIRC?)

Or you would leave that up to OEM-specific configuration that is somehow
passed from system to "app" when the app is launched.  

I think there's a limit to how far you will be able to here specify the
exact application standard, which includes APIs like that between OS (or
"application manager") and app.  But a single well-known name might be
useful still.

In fact... come to think of it - is this thing perhaps better defined in a
different specification, one which specifies an (automotive) web application
standard, rather than in the server specification?

>
> 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.

That's why I asked.  Is this assuming a local server, or a server
"anywhere".  Is it simply intended to be a well-known name to address the
*default* VIS server, wherever that exists in the entire routable
(inter)net.

>
> 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

I still think you might be doing something useful if the specification
requires (or perhaps recommends?) a well-known name for the default server.
But I'm trying to really get to the root characteristics of what that thing
is supposed to mean, before forming a final opinion.

Thanks
- Gunnar



>
-- 
Gunnar Andersson <gandersson@genivi.org <mailto:gandersson@genivi.org> >
Development Lead
GENIVI Alliance