ntnu-ihb / fmu-proxy Goto Github PK

In order to reduce complexity, replace the current ZMQ heartbeat system with HTTP calls

While immensely powerful, the JSON-RPC support is difficult to maintain. Especially if supported by multiple server implementations. As far as I know, this feature is not used. Should it just be removed?

README needs to be improved.

JVM clients should be made available through maven

It's better to pass

-DCMAKE_TOOLCHAIN_FILE=C:\vcpkg\scripts\buildsystems\vcpkg.cmake

through the command line.

This is also the recommendation from vcpkg

Remove the DependenciesKind enum from RPC definitions and use a String instead

Having both single and bulk read definitions in the RPC adds a lot of extra code. The FMI standard itself only have bulk read, and real production code will have to rely on bulk read for efficiency.

Hi,
I would very much like to hear from you, the person reading this.
Why are you interested in this project, have you tried it?
What is unclear, what can be improved?

Note that it is also possible to chat on gitter!

Readme is currently outdated. Should fix

It should be possibe to pass an URL to a running proxy-server, which will subsequently download and make the FMU available over the network.

Add heartbeating so that the server can be autodiscovered by the directory service

Bulk read/write should lead to considerable performance gain as fewer RPC calls per time-step are required.
FMI does not support this operation, but FMI4j is working on an extension in NTNU-IHB/FMI4j#125.

However, only frameworks that uses the extension, like Vico, will benefit from this.

Hello,
First of all, great work! The fmu-proxify feature is awesome! Working great when running all in the localhost.

I am getting "no main manifest attribute, in FMU-proxy.jar" both in windows 10 and Linux when I trying to "java -jar FMU-proxy.jar " on the target computer.

In practice there is no need to support two server implementations other than as a proof of concept. The JVM server is the preferred choice. This will make it easier to introduce new features.

C++ server and clients should be available through vcpkg

Rollback functions is defined in the RPCs, but has not actually been implemented by the servers.

With the other building blocks (fmi wrapper, heartbeating and thrift server) ready, we can finally create the final FMU-proxy executable.

Some co-simulation framework does not perform caching of variables. Thus it may repeat calls on getXXX. This is ok when network calls are not involved, but adds considerable overhead when getXXX leads to a RPC call.

Needs debugging. Probably related to fmuResourcelocation

Improve the project by adding support for JSON-RPC over WebSocket and TCP/IP

https://github.com/markaren/YAJ-RPC

Currently JDK8 is required due to usage of JAXB, which was removed from later JDK versions.

In the future, it should be possible to upload FMUs to the discovery service, which will automatically find a suitable proxy to run it on.

As a bare minimum, the allocator will have to consider things tool requirements, license requirements and platform requirements.

I run a setup using the Cosim demo app together with FMU-Proxy version 0.6.2.

The FMUs are hosted in an Nginx docker container and served to another container running the Cosim demo app through http.
FMU-proxy runs in a third docker container.

However, when running this setup I am not able to change the value of boolean inputs to the FMUs, and some boolean values are flickering between true and false.

I have confirmed that the same setup works when running the FMUs directly in the same container as the Cosim demo app.

As suggested in #71 , it would be nice if we were able to wrap one of the clients as an FMU.
This would allow distributed simulation to any FMI compliant tool without modification.

Obvious problem: The modelDescription.xml refers to a specific model.
Solution: Do not provide a modelDescription.xml. Let the user copy it from the target FMU and paste it into the archive we provide.

Similarly the IP and port could be put into a .txt file inside the archive.

https://www.appveyor.com/ is an option.
BUT
The initial un-cached run will take over 60 minutes, making the (free plan) build fail. I had the same problem with CircleCI (out-of-memory). The solution there was to use a docker image.

Handy if the FMU is present on the master PC, but not the remote server.

This feature requires the current load(URL) to be renamed to loadFromUrl.

Currently the fmu-proxy-gen (JVM) project generates FMU specific .proto files that allows users to get client side access to all variables in an FMU.

However, the feature is very hard to use. For each FMU a custom client has to be built....

We are better of removing this feature.

The project should not be tied to gRPC as more options will be added.

So should find a more suitable name.

As it is, the Avro support provides very little benefit. Avro RPC is not supported in many languages, and code generation exist in even fewer.

I think it is safe to remove this feature..

createInstanceFromME has not been implemented for the C++ server

Should make a C++ implementation of the server.
Only Thrift support to begin with, and no heartbeating

Supporting vcpkg is time-consuming since it always changes.. Lets use conan only.
I.e thrift is constantly changing, and sources generated with 0.12.0 is not compatible with vcpkg thrift.

These transports have had a history of causing hang-ups during testing. Better to remove them. It's easy to re-add them later if there is a strong wish for them to be present.

The C++ project cannot be built using conan at this point. Conan is introducing a lot of breaking changes lately. Should just wait it out I guess.

Currently, you spawn one proxy per FMU. The original reason for that was that the proxy provided instance specific getter and setters for variables. This feature has since been removed as it is considered to hard to use by the end user.

Causality, Variability and Initial

Needs more investigation...

JSON-RPC TCP server seems to be one of the sinners