Freemaster http latency

[Bohrfutter]

Hello Freemaster Team,

I am using the http interface of the Freemaster to connect to a remote target. Unfortunately, the latency of the tcp/ip connection is about 90ms (4g network). Is it possible to send e.g. 10 http requests in a queue? If the first request is answered by the target a new request could be initiated. Latency will still be slow but the datarate would increase and Freemaster use and feel would be much better. Preferable the number of open (parallel) http requests could be configured in the “Remote Server” dialog.

If this is not possible - do you thing this behavior could be implemented with a custom communication interface?

Background:

We need this behaviour to debug our application at the customer. We have developed an Android App and an Android USB-CAN adapter (RS232 is also possible). We send the phone and the adapter to a costumer and can connect to our target MCU via the Freemaster http protocol. Beside the Freemaster “tunnel” the device also logs CAN traffic for further investigation.

We think about commercialization of this product – so if anybody has a similar use case, feel free to contact me.

Best regards

Sebastian

[MichalH]

Dear Sebastian,

this is very interesting use case and a good idea. Unfortunately, FreeMASTER does not support this command queueing. The nature of the protocol implementation in a communication library is to send a command and receive response in a single DLL call. And even more, the same Send+Receive concept is also used in communication plug-ins, so you would not be able to do anything about this limitation even if you would write your own plug-in.

The only theoretical option I can think about now is to use FreeMASTER Lite on the remote side and expose its JSON-RPC interface to the public network. Then you would be able to prepare a batch of JSON-RPC messages on the client side and send them all at once over the network. Some minor modification of the client-side JavaScript implementation would be needed to achieve such queueing though. Also the responses would be sent back individually by the FreeMASTER Lite, but I guess the TCP layer could join them again to fewer physical frames thanks to naggle algorithm. I think we could support you by experimenting with queueing and buffering of the responses to enforce some optimizations on this side.

Bad thing is that the graphical data representation would not be possible to make in FreeMASTER, but you would have to write your own visualization. So my proposal is not so perfect after all. Let me know what you think. I will also discuss this idea internally in the team.

Thanks,
Michal

[Bohrfutter]

Hi Michal,

Thank you very much for the quick response! As you already mentioned I am not so happy with your suggestion .

Even it is a bit slow the Android tunnel is working like charm and all our other “tools” are working like before. We have several Excel sheets with ActiveX to read/write parameter to the ECU or read data from the “flight recorder” of the ECU and analyse them (e.g. statistics, histogram etc). Right know we use Teamviewer and have to install Freemaster at customer PCs – this is something we like to avoid in the future.

Maybe I already mentioned but Freemaster lite seems not to be a solution for our use case.

Even I don’t know the Freemaster architecture I suspect there must be some kind of request() and waitForAnswer() where a queue could be introduced. Maybe this queue could be a helpful feature if targeting other ECU interfaces with “high” latency and high data rate in the future.

Best regards

Seb

Btw: naggle was also a problem on Android and gave me some headache - but I managed to get 13ms rountrip on a local WLAN...

[MichalH]

Hello Sebastian,

OK, let's conclude that FreeMASTER tool and FreeMASTER protocol is not matching this use case. Although it would be potentially (hardly) possible to modify the internal state machine in FreeMASTER app to issue several commands down to a communication layer and then collect responses, the protocol itself is not as robust as it would need to be for such scenario. There is no request-response pairing identifier (like e.g. in JSON-RPC) which would assure the data consistency. 

Regards,
Michal