Input for NetworkProxy example

[ClemensLinnhoff]

In the modelDescription of the NetworkProxy example, it says "OSMPSensorViewIn". But in the OSMPCNetworkProxy.h, the integer variables contain "SENSORDATA_IN".

So does the NetworkProxy expect SensorView or SensorData as input, or does it work for both?

[ClemensLinnhoff]

Either way, I cannot get the NetworkProxy to work. I am using it just as a sender, so receiver is set to false. For address and port I use the default 127.0.0.1:3456. As a receiver, I am trying to use the osi visualizer (I know it is archived, but it should still be able to receive data via TCP, right?).

I am getting the following error:

Error setting up Socket Connection: 111 (Connection refused)

Any idea, what's wrong?

[ClemensLinnhoff]

@vkresch Do you maybe have an idea?

[pmai]

In the modelDescription of the NetworkProxy example, it says "OSMPSensorViewIn". But in the OSMPCNetworkProxy.h, the integer variables contain "SENSORDATA_IN".

So does the NetworkProxy expect SensorView or SensorData as input, or does it work for both?

The network proxy does not care about the contents of the messages, it will just forward the binary data as-is. The nomenclature in the code base comes from a time when everything in OSI was till SensorData, so was not updated, since this does not influence functionality.

[pmai]

Either way, I cannot get the NetworkProxy to work. I am using it just as a sender, so receiver is set to false. For address and port I use the default 127.0.0.1:3456. As a receiver, I am trying to use the osi visualizer (I know it is archived, but it should still be able to receive data via TCP, right?).

The error indicates that the FMU tries to connect to the given address and port, but nothing is listening on that port / and or a firewall is blocking the connection (unlikely but not impossible for a localhost connection). What does netstat -a say at the time?

[ClemensLinnhoff]

I thought so too, at first. But I could successfully implement a NetworkProxy using zmq.h. Therefore, it is not a listening error nor a firewall problem.

netstat does not list any connection at the used port.

[pmai]

If netstat is not listing the port, then nothing is listening on the port, so the error message is the correct one... So are you sure that netstat -a is not showing the port in state LISTENING?

[pmai]

If netstat is not listing the port, then nothing is listening on the port, so the error message is the correct one... So are you sure that netstat -a is not showing the port in state LISTENING?

Which BTW is probably unsurprising, since the osi-visualizer seems to want to connect to the source, i.e. it is the active part creating the connection, hence it is not listening but rather connecting.

So if you wanted to use the NetworkProxy with this, you'd have to configure it to be the listening side (config option FMU_LISTEN).

Not that I would recommend any of this (neither osi-visualizer, nor random proxy FMUs) for any productive use.

[ClemensLinnhoff]

If netstat is not listing the port, then nothing is listening on the port, so the error message is the correct one... So are you sure that netstat -a is not showing the port in state LISTENING?

The port is not listed. I have something listening at localhost:

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 localhost:domain        0.0.0.0:*               LISTEN     
tcp        0      0 view-localhost:ipp      0.0.0.0:*               LISTEN 

But this is also listens, when the visualizer is not active.

So if you wanted to use the NetworkProxy with this, you'd have to configure it to be the listening side (config option FMU_LISTEN).

I set the (unfortunately undocumented) FMU_Listen option to true.

netstat now lists it:

tcp        0      0 view-localhost:3456     0.0.0.0:*               LISTEN 

The FMU waits, until I activate the visualizer, then I get the following error message:

Got 00005591 33237340 LEN 00018B0D, reading from 0x559133237340 (length 101133)...
Failed to send message size (101133): 104 (Connection reset by peer)

And the visualizer also throws and error:

SensorView receiving error

[pmai]

The FMU_LISTEN option (which is as undocumented as anything else in this example) also isn't documented because it is usually a bad idea, given that it has to wait for an inbound connection, and hence has to block, which an FMU simulator might not be prepared for.

When using an FMU proxy, usually the other side should be the listening side.

The error messages seem to indicate that the proxy is working, but that the receiving side has trouble with what it is receiving and hence breaking off the connection.

Glancing at the abandoned osi-visualizer code base, it seems to me that the TCPReceiver is not aptly named, in that it seems to be a ZeroMQ receiver, rather than a native TCP receiver; more specifically it also does not follow the protocol that the Proxy expects, in that the proxy sends a length field, and then the data - given that pure TCP is a stream-based protocol, which does not preserve message boundaries, or rather has no concept of a message, this is needed because otherwise the receiving side would not know how much to read.

The osi-visualizer uses ZeroMQ, and hence likely reads the length field into something it considers a message, and when the osi-visualizer then tries to parse whathever it got as a sensorview, this will fail.

Again, I'm unsure what you are trying to acomplish resurrecting deprecated stuff, but I do not think this ever was intended to work as a OSMPCNetworkProxy receiver. Note also that the example code in here is just that, i.e. example code. There are usually better solutions than just randomly plugging network proxies into systems.

[ClemensLinnhoff]

Thank you for the detailed explanation! To me, it wasn't so far fetched to think, that if there is a visualizer receiving OSI via TCP and in the same organization an example on how to send OSI via TCP, they are compatible.

Anyways, I have a solution now, that works using ZeroMQ. We will put it in OpenMSL in the near future and then, we could maybe link it in the Readme here as an additional example.