davetcc
Support device remotes that connect to an accepting server - IE reverse connection direction.
Is your feature request related to a problem? Please describe. Sometimes, when we need to connect with a server there is a need for reverse direction logic. IE where the board opens a connection to a remote server. This server could be on the public internet, and would most likely need encryption, but that is to be discussed in another ticket.
Describe the solution you'd like That the connection were able to be reversed on both the Java API and the board. There is a library issue to track this, and also in future I will create a C# ticket for this as well.
I am building out examples in tcMenuJavaApi/src/test/java/com/thecoderscorner/menu/examples they will include both a server and client to exercise this functionality.
@davetcc I see you added some initial support and examples. I will start building my solution and test this implementation. I will update this thread.
Thanks!
I would just look at the implementation for now and feedback on what you think at an overall level. I need to do a bit more work on it yet to get it working properly.
So far I have integrated your example into a Spring Boot application. TcMenu runs on one port and REST API on another. This required building the JavaAPI library from sources but it wasn't complicated.
I also found out that the interoperability with Kotlin is well supported in Spring. Therefore I use that.
Tomorrow I will create a dev branch in my Arduino firmware and after that I will provide some feedback.
First observation,
I assume the ClientEthernetTransport will be included into the code via the generator where user enters the IP address and port. Since the IP address is a string, it will help if TcMenu supports entering a constant instead of the string. This would be similar to setting the project name.
IP address will change between environments and having this option will help users better manage this situation.
With the latest commit I had it working this morning.
I assume the ClientEthernetTransport will be included into the code via the generator where user enters the IP address and port. Since the IP address is a string, it will help if TcMenu supports entering a constant instead of the string.
Agreed, I will give the option of a variable or constant.
IP address will change between environments and having this option will help users better manage this situation.
Agreed, it would be somehow configurable, at least as a property. I would imagine it would in most cases point to a DNS entry, IE a host name. Will check what happens if a DNS name entry is passed to the connect call.
OK, I will test that as well. I was also thinking about connection retries.
Imagine the network is not available when the TcMenu is initialized. In the normal scenario an app will connect on demand to the device and it will either work or fail. However, when we have a server, it is necessary the device makes periodic attempts to connect to the server.
What is the current behavior? I'm not that familiar with the TcMenu network code.
It looks like the connection is re-established after a network failure or something. I have a successful connection.
I have another observation. Who sets the heartbeat interval in this case?
Irregards of who sets it, it should be configurable (i.e., not set in the generated code).
Receiving a heartbeat every 1.5 seconds is OK for a local connection but it utilizes the server too much. Imagine having 1000 connections sending heartbeat so often.
By default - for this mode of connection - I would say a heartbeat once per 30 seconds is reasonable, maybe even a minute.
The logic is the same as for the other device cases, the device sets the interval, and it is configurable at the moment by compiler definition. I think yes, it should be configurable per connection, the current situation is not great, and I will make that change so that it can be configured per connection. The memory overhead for that is minimal. I will see how much work it is to expose on the properties of the code generator.
The latest commit on the library allows the heartbeat frequency to be adjusted. It is so trivially simple to set manually that I am inclined not to try and add this to the code generator.
I checked the commit and as you say, it was trivial. I like this change.
This is now working in both Java and C++/device. Closing this issue and we'll open additional new ones as it is productionized.