What is the point of org.fmi-standard.fmi-ls-xcp.ListenIpAddress?

[adriantirea]

fmi-ls-xcp says there must be a structural paramere for IP Address where to listen for XCP commands. But the connection is the other way around. The MDC tool needs to know the IP Address of the XCP service to connect to.
The XCP Service is listening on the specified port and protocol type (obs. protocol missing in current fmi-ls-xcp). The XCP service does not need an IP Address to listen from.

    org.fmi-standard.fmi-ls-xcp.ListenIpAddress
        Description:  "IP address where the XCP slave listens for XCP protocol commands."
        Type:         String
        Causality:    structuralParameter
        Variability:  fixed
        Start:        "127.0.0.1"

Is there a case I do not see where it make sense the org.fmi-standard.fmi-ls-xcp.ListenIpAddress?

[pmai]

    org.fmi-standard.fmi-ls-xcp.ListenIpAddress
        Description:  "IP address where the XCP slave listens for XCP protocol commands."
        Type:         String
        Causality:    structuralParameter
        Variability:  fixed
        Start:        "127.0.0.1"

Is there a case I do not see where it make sense the org.fmi-standard.fmi-ls-xcp.ListenIpAddress?

I think the idea behind the structural parameters is to influence the port/address that the built-in XCP slave of an FMU should listen on, i.e. the FMU importer can tune the port (and potentially the address) that the XCP slave inside the FMU will bind to (hence the parameter needs to be structural, to allow changes prior to actual FMU/simulation startup).

The address part of that makes sense to restrict the addresses the slave listens to (i.e. only localhost connections when listening on 127.0.0.1 vs. outside connections when listening to one of the actual IP addresses of the host).

Now I think this must be made optional, both for FMI 2.0 support (which does not have structural parameters) as well as for the use cases where the FMU has no control over the XCP slave (e.g. we have FMU remoting, where the XCP slave runs on the system the actual FMU runs on, but the simulator uses a client FMU; here the client FMU will not control the XCP slave, and it will never run on the local machine; there are other such use cases).

I also think that protocol information (i.e. to support XCP via UDP as well as XCP via TCP) would be needed, and potentially the IP address parameter should be an array, to allow for listening on multiple interfaces.

But at least this is my understanding of this feature. Given that there seems questions over it, I think it needs to be described more specifically, and also some of the assumptions that the XCP slave lives inside the FMU should probably be dropped...

[adriantirea]

I learn a bit more on the subject.
The listen IP address for a connection can be restricted as @pmai has just said. Also there is the option of listen on any IP on your machine: INADDR_ANY == 0.0.0.0.

My proposal then is:

• make it optional. The default is INADDR_ANY == 0.0.0.0.
• allow the IP address structural parameter. The values expected are one or a list of IP addresses.

The port TCP or UDP selection is covered in #19

[PTaeuberDS]

We should add a non-normative sentence about what proper start value can be used for ListenIpAddress (localhost or 0.0.0.0). There should be no normative text about it.

[PTaeuberDS]

What configuration options should the ListenIpAddress parameter provide?
Option 1: We do not need a parameter -> It's up to the implementer
Option 2: The parameter is a scalar -> 127.0.0.1, 0.0.0.0 or specific address
Option 3: The parameter can be an array -> Like option 2, but multiple specific addresses can be listened to.
Option 4: Replace the current structural parameter by an optional calculated parameter

Op 1: 6
Op 2: 0
Op 3: 0
Op 4: 8
Abstain: 1

[PTaeuberDS]

Addressed in #26/#27, respectively, but in a more flexible and general way (see comment in #14).