I would like to make a few suggestions for this new version, as well as help explain a few things that may not be clear:
With VNC you have a "host" and "viewer".
- The "Host" is the device that you want to view/control, so it is acting like a webserver. You could connect to the host like a browser connects to a webserver and the "Host" generate the screenshots like a webserver would generate webpages.
- The VNC "Viewer" is like a browser in the above example, you direct the vnc viewer to connect to a vnc host and then the viewer will show you the streaming screenshots from the host (and allow you to send keystrokes and mouse movement to the host device).
Typically to connect to a host, you just need the host's IP address and port number and password - that's is. You would then enter this info into the viewer and the viewer would connect to the host and then allow the viewer to see and control the host.
Often the host would be your client's PC or wireless device. However, their device might be behind a firewall or a cellphone network who's IP address often changes (and a lot of cellular companies don't allow "incoming" connections to cell phones). In these situations, it's not possible for the viewer to connect "to" the host.
Below are two problem scenarios (like the one just mentioned above) and my suggestions for addressing them that I hope
sfsameer could consider for this next version:
1) "Variable" Host, "Fixed" viewer:
The "Host" (the client) is behind a firewall, or is running on a device with a changing IP (cell phone) and/or doesn't allow for incoming connections.
The "Viewer" (the support company, ie "Me") is a desktop PC with a fixed IP address and a firewall/router that can be configured to route incoming connections to the PC's viewer app.
Solution: Allow for the host and viewer apps to perform a "reverse connection". This way, the "viewer" on my PC would be configured to "listen" for an incoming connection from a host. Since my PC is at a fixed IP address, I can provide that address and the configured/forwarded port to the client so that they can enter it into their "host" app. The host app would make a connection into my viewer app and then I could see and control the client's device from my PC. This method eliminates the problem in which the host app can not accept incoming connections, but the viewer app can.
2) "Variable" Host, "Variable" Viewer:
The "Host" (the client) is behind a firewall, or the host is on a device with a changing IP (cell phone) and/or doesn't allow for incoming connections.
The "Viewer" is also behind a firewall, or running on a device who's IP address changes and/or doesn't allow incoming connection.
Solution: Setup a "Proxy" to connect the two to each other.
For this scenario, a proxy would be run on a cloud server and below is my suggestion on how it would work:
1) The "host" app would be designed to make short repeating connections every 5 second or so to this "proxy", basically telling the proxy that this particular host is ready for a connection.
2) The "Viewer" app would then connect to this proxy and the proxy will return a list of hosts that are ready for a connection to the viewer app. When I select a host from the list, the proxy will then return an IP address and port number that the viewer app will then use to connect to tat host. The proxy will then act as a true proxy and reroute all the packets from the viewer app to the host app and visa versa using the IP address and port number the proxy setup to do this exchange. It should route these packets directly between the input and output sockets without the use of a database - this way throughput will be maximum and server load be minimum.
By utilizing a "proxy" for this scenario, it would allow the client to run the host app on their smartphone over a cellular network, and then allow me to control (offer remote support) the client's device from my smartphone which is also operating over a cellular network.
I hope all this makes sense and I look forward to any comments on this.