VNC Server & Client : Source Code For Sale

[sfsameer]

First, thank you for reading my post and I totally understand that a "proxy" function will not be part of the first release of this new VNC source code.

I do want to just express a few thoughts for when you do add the proxy feature...

I understand when you talk about automatically setting up new rules for a firewall, or using a VPN to connect the host and viewer together. But I think these methods will require either a configurable firewall or require the user to manually setup and install a VPN - both of which may not work easily over a cellular connection.

This is how I hope the "proxy" feature will work:

1) The end user will simply run a "host" app on their device which will then display some unique connection "code".
2) I will enter that connection code into the "viewer" app running on my phone and then I can connect and see/control the user's device even if we both are on a cellular network.

It would be great if everything could work just that simple (no firewall rules, no vpn needed). This way I can Easily offer Immediate support to my clients without them having to jump through hoops to setup anything.

Hello Dear,

Because we have started the updates loop so i have 2 questions if i may regarding the public remote connection without setting up the router :
1- Should we use the same method as the TVA which is a middle ware server that transmits the connection data between clients through web sockets?
2- Should we use a proxy server to enable both parties to connect to each other without the need to open a port in the router?

Note : Option 1 & Option 2 will need a middle ware server to receive and send requests.

Thank you,
Saif

 

[JohnC]

Hello Dear,

Because we have started the updates loop so i have 2 questions if i may regarding the public remote connection without setting up the router :
1- Should we use the same method as the TVA which is a middle ware server that transmits the connection data between clients through web sockets?
2- Should we use a proxy server to enable both parties to connect to each other without the need to open a port in the router?

Note : Option 1 & Option 2 will need a middle ware server to receive and send requests.

Thank you,
Saif

Before I answer your above question, I would like to first reiterate the three use-cases that I hope the next update can support:

1) The first use-case is to have both the host and server support "reverse connections". For example, I could setup port-forwarding on my office pc so it will route "incoming connections" on a particular port from external "hosts" app to my PC. Then I would run the "viewer" app in reverse connection mode so it is waiting for an incoming connection from a "host" app. Since I have control over my end of the connection, it is easy to setup this port-forwarding in my router.

Then, I would create a custom version of the host app that would be hard-coded to make a reverse connection to the IP address of my office pc. This would then allow my client to simply run the custom host app and connect to my waiting viewer app - allowing me to support them immediately.

I am only mentioning this use-case because I hope the next update for your host and viewer apps can support reverse connections so that they can connect to each other without the need for any "middleware" (just as VNC is designed to do).

Next, I can see at least two different use-cases where middleware would be needed:

2) I have a bunch of remote (and unattended) PC's that I need to remotely maintain (which I am looking to change to android devices soon). I am hoping that the next update of your host and viewer can operate in a mode that uses a middleware server that would allow a viewer app running on my PC to connect to any of those remote pc's at any time. So, I am thinking that I would configure each of the remote PC's to auto-load your host app to run it when the PC boots up. These host apps would then contact the middleware server every 10 seconds or so to let the middleware server know that the pc is available to be connected to. Then the viewer app would have the ability to connect to the middleware server and get a list of all the available pcs that can be connected to. Then all I would have to do is click on a host PC name and my viewer app will connect to the remote host app and allow me to control it.

In this configuration, I'm thinking that it would be best to not require any routers to be pre-configured with port forwarding, so that the host and viewer app can connect to each other even if both ends have dynamic IP addresses and also that they may not have the ability to configure their firewall/router at all.

3) The final use-case is the ability for me to be able to still support one of my clients when I am not back at my office. In this situation, it would not be practical for the clients host app to be hard coded to make a reverse connection to a fixed IP address because my portable PC or smartphone device will probably be using a connection with a dynamic IP address. In this use-case, middleware will be needed to connect the client's host app to my viewer app.

Maybe the host app could allow the client to type in their name when they first run the host app and their name will appear in the list of the available devices that my viewer app will list as available to connect to, just like the above #2 use-case. I could then click on their name and my viewer app would be connected to their host app.

I just wanted to mention the above use-cases so that they might help give you ideas for the next update of this project.

Now, to answer your question....I think it would be best to:

1) Design the middleware to utilize a database but only for the purpose of managing what devices are available to connect to.
2) Then when I click on a host device to connect to, the middleware will then act as a proxy to route the packets between the host and viewer directly to each other without any overhead (like going through a database like the TVA did).

I hope all this makes sense and I am very much looking forward to the next update!

 

[sfsameer]

Before I answer your above question, I would like to first reiterate the three use-cases that I hope the next update can support:

1) The first use-case is to have both the host and server support "reverse connections". For example, I could setup port-forwarding on my office pc so it will route "incoming connections" on a particular port from external "hosts" app to my PC. Then I would run the "viewer" app in reverse connection mode so it is waiting for an incoming connection from a "host" app. Since I have control over my end of the connection, it is easy to setup this port-forwarding in my router.

Then, I would create a custom version of the host app that would be hard-coded to make a reverse connection to the IP address of my office pc. This would then allow my client to simply run the custom host app and connect to my waiting viewer app - allowing me to support them immediately.

I am only mentioning this use-case because I hope the next update for your host and viewer apps can support reverse connections so that they can connect to each other without the need for any "middleware" (just as VNC is designed to do).

Next, I can see at least two different use-cases where middleware would be needed:

2) I have a bunch of remote (and unattended) PC's that I need to remotely maintain (which I am looking to change to android devices soon). I am hoping that the next update of your host and viewer can operate in a mode that uses a middleware server that would allow a viewer app running on my PC to connect to any of those remote pc's at any time. So, I am thinking that I would configure each of the remote PC's to auto-load your host app to run it when the PC boots up. These host apps would then contact the middleware server every 10 seconds or so to let the middleware server know that the pc is available to be connected to. Then the viewer app would have the ability to connect to the middleware server and get a list of all the available pcs that can be connected to. Then all I would have to do is click on a host PC name and my viewer app will connect to the remote host app and allow me to control it.

In this configuration, I'm thinking that it would be best to not require any routers to be pre-configured with port forwarding, so that the host and viewer app can connect to each other even if both ends have dynamic IP addresses and also that they may not have the ability to configure their firewall/router at all.

3) The final use-case is the ability for me to be able to still support one of my clients when I am not back at my office. In this situation, it would not be practical for the clients host app to be hard coded to make a reverse connection to a fixed IP address because my portable PC or smartphone device will probably be using a connection with a dynamic IP address. In this use-case, middleware will be needed to connect the client's host app to my viewer app.

Maybe the host app could allow the client to type in their name when they first run the host app and their name will appear in the list of the available devices that my viewer app will list as available to connect to, just like the above #2 use-case. I could then click on their name and my viewer app would be connected to their host app.

I just wanted to mention the above use-cases so that they might help give you ideas for the next update of this project.

Now, to answer your question....I think it would be best to:

1) Design the middleware to utilize a database but only for the purpose of managing what devices are available to connect to.
2) Then when I click on a host device to connect to, the middleware will then act as a proxy to route the packets between the host and viewer directly to each other without any overhead (like going through a database like the TVA did).

I hope all this makes sense and I am very much looking forward to the next update!

Hello Dear,

You know what i love about talking to you? you are a very detailed person which makes our lives easier, so thank you for that ❤

1- Consider it done
2- Consider it done

--------
1- Consider it done
2- Consider it done

As always, Thank you,
Saif

 

[Xfood]

good morning Saif, I had the opportunity to try this splendid work you have done in these days, at the moment it is fantastic, I imagine that the next update will be amazing. Thanks Saif, keep it up.

 

[Louis Moskowitz]

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.

Hi All.
I have made a similar suggestion to the developers in private and if they can solve this conundrum (host behind a firewall) we would truly have a a TeamViewer / AnyDesk RealVNC alternative. I would be happy to contribute to this kind of development. RealVNC offer this as a cloud service. See: https://www.realvnc.com/en/news/what-vnc-cloud/

Would anyone else contribute to some sort of "crowd funded development" for Saif and his team to tackle this?

Thanks
Louis

 

[Xfood]

certainly, Saif and his team are very good, and they deserve our support

 

[JohnC]

I think they are already working on a "middleware" program that we will be able to run/host on our own web servers, so we would not need a third party cloud server.

 

[jose luis gudino]

Future Updates :
1- B4A Client, the android client will be able to fully control the server side (host)
2- File Transfer
3- Able to use any VNC viewer to view the Server side (Host)
4- Hidden Mode/Stealth Mode

HI, how long will the new features be up and running?
Thank.

 

[sfsameer]

HI, how long will the new features be up and running?
Thank.

Hello,

From Post #96
The next update will be 31-05-2021 11:00 PM GMT 3+

Thank you,
Saif

 

[jose luis gudino]

Excellent
Thank

 

[Louis Moskowitz]

I think they are already working on a "middleware" program that we will be able to run/host on our own web servers, so we would not need a third party cloud server.

Just to be clear, we would not be able to use the RealVNC cloud broker service, it is for their version. I was just sharing it as reference as to what we need Saif and his team to do to be able to have an alternative to RealVNC.

Great to hear that they are working on a solution.

Thanks
Louis

 

[Louis Moskowitz]

Hello Dear,

You know what i love about talking to you? you are a very detailed person which makes our lives easier, so thank you for that ❤

1- Consider it done
2- Consider it done

--------
1- Consider it done
2- Consider it done

As always, Thank you,
Saif

Wow, I missed this. Totally agree that this is a very precise and clear description of what we need. Thanks Saif and team for undertaking to get 1 & 2 done.

Louis

 

[Louis Moskowitz]

See I did not actually buy this source as yet. Just paid now.
Louis

 

[sfsameer]

See I did not actually buy this source as yet. Just paid now.
Louis

Payment received, thank you very much for your purchase

 

[sfsameer]

Hello everyone

The update was scheduled to be uploaded today at 11:00 PM GMT 3+ but we will have to delay it just a little bit longer (less than 24 hours) because we are making sure that the code is understandable and bugs free so bear with us

❤

Thank you,
Saif

 

[amorosik]

I still don't understand if this system can also be used for remote assistance from PCs to Android phones that are not manned
I mean, how do you know the network address of the phone?
And even if you know it, how do you start a connection from pc to phone?
Obviously I'm talking about a telephone connected only via the telephone data network

 

[sfsameer]

I still don't understand if this system can also be used for remote assistance from PCs to Android phones that are not manned
I mean, how do you know the network address of the phone?
And even if you know it, how do you start a connection from pc to phone?
Obviously I'm talking about a telephone connected only via the telephone data network

Hello,

Simply :
1-In a local connection you can connect both PC and Android through local IP address and port (Direct Connection)
2-In a public connection : We did this in Teamviewer alternative V1 & Web Control (TVA V2) where we do have a middle ware server (Non-UI B4J) that receives the packets (byteBuffer, inputs, gestures, etc...) and sends them to the receiving the point (Point A) , once point A receives the packets then it will send the response (Updated byteBuffer, etc...) to Point B and all of this information exchange will be in a loop until the connection is disconnected.

 

[ocalle]

Hi
In the interest of consulting, even with the version now released with B4x code you can access a remote pc knowing the public ip (and enabling the firewall) right?
ty in advance

 

[sfsameer]

Hi
In the interest of consulting, even with the version now released with B4x code you can access a remote pc knowing the public ip (and enabling the firewall) right?
ty in advance

Hello,

Yes, as soon as you activate the port in your firewall your PC will be exposed to the internet and the VNC client will be able to connect to the VNC server.

Thank you,
Saif

 

[sfsameer]

Hello Everyone

After Writing 9 classes from scratch, Wrapping 29 classes, The B4A VNC Viewer simple version is born
Currently it's only used to view the server, no inputs, gestures, etc.. just for viewing.

**But this is the first version which means there will be many more version coming very soon, because the most difficult part is over which is :
1- Connecting to the server socket
2- Establishing the handshake
3- Encrypting and decrypting the password using : androidx.security:security-crypto
4- Enabling the color mode 256 and reading the bytebuffer
5- etc... (and many many more steps to accomplish the connection & the viewing)


-Below is the viewing demo (Keep in mind that the viewing activity is set to landscape so in the video it shows very small but in reality it's in landscape mode) :


Or you can view the video from the below URL :

http://b4xcode.com/b4avncdemo.mp4

-You can use it to connect to any VNC server BTW and not just B4J VNC Server

Before downloading the source code you need to know that there are 3 important libraries :
1- #AdditionalJar: androidx.security:security-crypto So make sure you open B4A SDK manager to download it
2- #AdditionalJar: tink-android-1.6.0.jar So make sure you put it in the additional libraries folder
3- VNCB4AClient.jar & VNCB4AClient.xml Make sure to put them in your internal libraries folder

*Please use the same download link we sent you earlier to download the B4A VNC Version and you will see a new file under the name : "VNCB4AClient.zip"

One last thing, the connection and the viewing is established by 2 lines of code in B4A because everything is happening in the libraries :

B4AVNCClient1.mainSettings(Main.ServerIP,Main.ServerPort,Main.ServerPassword)
    B4AVNCClient1.StartViewer(img1)

**The next update is coming very soon which will contain the B4A VNC Server, so stay tuned

Thank you,
Saif