Qt WebGL streaming plugin - Remote UI

[nsourl]

Hi all,

I am highly interested in using this awesome Qt WebGL streaming plugin ( https://doc.qt.io/qt-5/webgl.html ) for remote UI access of a personal Qt application that it's running on a Raspberry Pi. I am using the Qt 5.11.3 since it's the latest Qt version supported by the official Rasbian Debian Buster. So, I have these questions questions if anyone can help me:

1. Is it possible to use WebGL streaming plugin behind NAT or VPN and also use port forwarding ? Because I would like to have access of remote UI from my home or my mobile phone for checking status periodically and etc.

2. Qt WebGL streaming plugin supports encrypted connections like https? Or using encrypted websockets or something else? If yes, it is supported on Qt 5.11.3 version? And any idea how to do that?

3. I know that Qt WebGL streaming plugin allows by default only one connection at the time. So, any ideas how to support multiple clients?

Thanks.

[raven-worx]

@nsourl
ad 1) like any other application when port forwarding is properly setup. Or like in a vpn you already have "direct" access to the machine running your application

ad 2)
you may want to read this: https://www.qt.io/blog/2018/11/23/qt-quick-webgl-release-512
a bit outdated though, but i am not aware that it is supported yet (but doesnt mean it isnt)

ad 3)
a possibility is to design your application the way that the UI is strictly decoupled from the logic and each UI client accesses a single backend service. This way each UI client instance launched accesses the same data simultaniously.

[nsourl]

@raven-worx said in Qt WebGL streaming plugin - Remote UI:

@nsourl
ad 1) like any other application when port forwarding is properly setup. Or like in a vpn you already have "direct" access to the machine running your application

ad 2)
you may want to read this: https://www.qt.io/blog/2018/11/23/qt-quick-webgl-release-512
a bit outdated though, but i am not aware that it is supported yet (but doesnt mean it isnt)

ad 3)
a possibility is to design your application the way that the UI is strictly decoupled from the logic and each UI client accesses a single backend service. This way each UI client instance launched accesses the same data simultaniously.

@raven-worx ,

1. I tried to forward webgl commands (using -platform webgl:port=8081) of my Raspberry Pi application through NAT on a public accessible IP address. I am having a problem that the websocket port dynamically changes each time that I run my app. So, I have to port forward the traffic from this port on public IP address too. After adding the websocket port to be forwarded, then it's possible to run remotely. But do you have any idea if I could request from WebGL plugin to select a specific port for the websocket? I was looking into the source code but I am not sure what I have to call and if it's exactly what I need.

2. Thanks for sharing this blog post and after checking the source code of the WebGL plugin it seems that the websocket supports encryption but it's not supported by the httpserver that is being used right now. So, probably https is not supported by this plugin yet. But I found this repository on github about qthttpserver and it seems from a specific commit that https is supported. Do you think that this may help me somehow ?

3. It sounds a very good idea about the deisgn of my application.

Thanks!

[raven-worx]

@nsourl said in Qt WebGL streaming plugin - Remote UI:

1. ah i didnt know this parameter yet. Should be the following then i guess:

-platform webgl:port=8081:wsserverport=8082

2. no, unless you want to rewrite the internal "HTTP server" code

[nsourl]

@raven-worx said in Qt WebGL streaming plugin - Remote UI:

@nsourl said in Qt WebGL streaming plugin - Remote UI:

1. ah i didnt know this parameter yet. Should be the following then i guess:

-platform webgl:port=8081:wsserverport=8082

2. no, unless you want to rewrite the internal "HTTP server" code

@raven-worx ,

1. It worked using the command line format as you proposed. But also I had to find the corresponding branch where this command line parameter is supported. For example on Qt 5.11.3 this parameter is not supported. I think it's supported from Qt 5.13.0 and above.

2. Ok then, appreciate for your advice.

Thanks.