Update: UltraVNC 1.4.3.6 and UltraVNC SC 1.4.3.6: https://forum.uvnc.com/viewtopic.php?t=37885
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
Nat2Nat Server To Be Released and SC integration
Nat2Nat Server To Be Released and SC integration
So,
Rudi has said that he will release the nat to nat server piece soon. That's great news. What we need to do as a community is to get started trying to implement the nat2nat connection (clients) into the SC distrobution.
At this point we will truely have a GoToAssist type of setup. This for me was the last missing peice of the puzzle. For those of you that don't know, we were able to do a nat to nat connection using the repeater BUT using the repeater seriously henders performace as ALL traffic has to be relayed.
With nat2nat a publicly addressable server provides a mediated connection (acts as the traffic cop, to setup a conneciton) that ends up being a DIRECT nat to nat (kinda like p2p) connection. There is no middle man once the connection is established.
RUDI,
Can you help us so that we can get some iteroperability for SC? So that the Nat2nat client will make the connection and then run the normal WinVNC.exe. Best case senario would be to make a special EXE like SC that has the nat2nat client built in. Can you add this client to SC.exe and then a line in the INI? This would be IDEAL.
Thanks and I'm REALLY excited about having Nat2Nat...the holy grail for us SC users.
THANKS!!
Rudi has said that he will release the nat to nat server piece soon. That's great news. What we need to do as a community is to get started trying to implement the nat2nat connection (clients) into the SC distrobution.
At this point we will truely have a GoToAssist type of setup. This for me was the last missing peice of the puzzle. For those of you that don't know, we were able to do a nat to nat connection using the repeater BUT using the repeater seriously henders performace as ALL traffic has to be relayed.
With nat2nat a publicly addressable server provides a mediated connection (acts as the traffic cop, to setup a conneciton) that ends up being a DIRECT nat to nat (kinda like p2p) connection. There is no middle man once the connection is established.
RUDI,
Can you help us so that we can get some iteroperability for SC? So that the Nat2nat client will make the connection and then run the normal WinVNC.exe. Best case senario would be to make a special EXE like SC that has the nat2nat client built in. Can you add this client to SC.exe and then a line in the INI? This would be IDEAL.
Thanks and I'm REALLY excited about having Nat2Nat...the holy grail for us SC users.
THANKS!!
-
- 8
- Posts: 13
- Joined: 2005-03-30 20:00
Re: Nat2Nat Server To Be Released and SC integration
Maybe I'm missing something, but both the Nat2Nat and the Repeater service (when running on a public IP machine) do exactly the same job.cheaha wrote:For those of you that don't know, we were able to do a nat to nat connection using the repeater BUT using the repeater seriously henders performace as ALL traffic has to be relayed.
With nat2nat a publicly addressable server provides a mediated connection (acts as the traffic cop, to setup a conneciton) that ends up being a DIRECT nat to nat (kinda like p2p) connection. There is no middle man once the connection is established.
There is no way to connect two machine from two private networks (with local IP addresses) without somekind of a relay between them (The reason for that is the limitations of the IP protocol). This relay service might be the Repeater, or the Nat2Nat server with it's two clients...
I don't see how the Nat2Nat will work quicker than the repeater. So if anybody knows the answer, I will be glad to know...
Thanks.
Re: Nat2Nat Server To Be Released and SC integration
The diference between repeater and NAT2NAT is that the repeater is ALWAYS in the middle of the viewer-server communication, instead NAT2NAT is used ONLY to establish the initial communication, and after that everything works like a Point to Point link between both ends.nir_kornfeld wrote:I don't see how the Nat2Nat will work quicker than the repeater. So if anybody knows the answer, I will be glad to know...
Thanks.
If I'm wrong ... please let me know !!!
HTH
-
- 8
- Posts: 13
- Joined: 2005-03-30 20:00
Re: Nat2Nat Server To Be Released and SC integration
You are wrong.Sergio wrote:The diference between repeater and NAT2NAT is that the repeater is ALWAYS in the middle of the viewer-server communication, instead NAT2NAT is used ONLY to establish the initial communication, and after that everything works like a Point to Point link between both ends.
UltraVNC is based on the TCP/IP protocol. Please read this article, then continue reading:
[post=10152][/post]
The IP protocol uses the Source Address & Port and the Destination Address & Port to "know" from where the packet is comming and to where it is going, plus, to know to where the reply packet should ne delivered.
When establishing a connection between two machines behind two different NATs there is no real address that the IP header can contain. It must ALWAYS use the Nat2Nat server or a repeater server (with public IP address) - Thus making the Nat2Nat and the Repeater identical.
The differences are:
1. Nat2Nat is using a server somewhere in the internet, and two clients (one on each side)
2. The Repeater need a machine with public IP (that you must provide) but needs no extra clients (the UltraVNC server and viewer support it out-of-the-box)
Based on the fact that the TCP/IP packet can not travel directly from one machine behind a NAT to another machine behind a (different) NAT - There is no way that Nat2Nat can establish a real p2p connection.
And that means that both the Repeater and the Nat2Nat options works the same speed.
- Rudi De Vos
- Admin & Developer
- Posts: 6863
- Joined: 2004-04-23 10:21
- Contact:
UltraVNC is based on the TCP/IP protocol, that's the reason
you need to run the 2 helpers.
The Nat helpers encapsulate the tcp in udp streams.
vnc (tcp) <-->(tcp)nat helper(udp)<---> nat router
Udp packets don't need a 3the machine to travers a NAT router
I don't know if it is faster for a single connection, the tcp to udp conversion
(reliable) also has an overhead.
But with multiple connections it does not depend on the 3the machine bandwidth.
you need to run the 2 helpers.
The Nat helpers encapsulate the tcp in udp streams.
vnc (tcp) <-->(tcp)nat helper(udp)<---> nat router
Udp packets don't need a 3the machine to travers a NAT router
I don't know if it is faster for a single connection, the tcp to udp conversion
(reliable) also has an overhead.
But with multiple connections it does not depend on the 3the machine bandwidth.
-
- 8
- Posts: 13
- Joined: 2005-03-30 20:00
UDP, like TCP is based on the IP layer:Rudi De Vos wrote:UltraVNC is based on the TCP/IP protocol, that's the reason
you need to run the 2 helpers.
The Nat helpers encapsulate the tcp in udp streams.
vnc (tcp) <-->(tcp)nat helper(udp)<---> nat router
Udp packets don't need a 3the machine to travers a NAT router
The difference between UDP and TCP is the fact that UDP is much simple, faster, but have no error control, duplicate handling and some more features that TCP has. That's why it is less reliable than TCP.
(For more information: http://www.erg.abdn.ac.uk/users/gorry/c ... s/udp.html)
Because both protocols are based on the IP layer, they "travel" on the net using the source address / destination address fields in the IP header.
As I wrote before, I don't know of a way to travel from one machine (with private internatl IP address) to another machine (with a different address on a different private network) without somekind of a 3rd machine that bridge them.
Yes it does. The 3rd machine is responsible for bridging the other, every packet, even if it is encapsulated inside a UDP packet, travels from the first machine to the 3rd one, and then to the 2nd. The 1st and 2nd machines do not know each other's IP address, because they both have private addresses and not public ones. Only the 3rd machine need to have a public address.Rudi De Vos wrote:But with multiple connections it does not depend on the 3the machine bandwidth.
BOTTOM LINE: Nat2Nat is still more effecent than repeater service. Even if it still is in the middle a little, there is much less traffic bridged.
Rudi,
Is there any way we can get the helper files added to the main EXE for a SC distrobution, so that we can specify our own Nat2Nat Server?
Rudi,
Is there any way we can get the helper files added to the main EXE for a SC distrobution, so that we can specify our own Nat2Nat Server?
Last edited by cheaha on 2005-04-25 15:10, edited 1 time in total.
Redge,redge wrote:cheaha
[topic=2211][/topic]
Yeah, I know I've brought this up before, I've been wanting Nat2Nat in a SC.exe for some time. Thanks. [/img]
Last edited by cheaha on 2005-04-25 16:48, edited 1 time in total.
- Rudi De Vos
- Admin & Developer
- Posts: 6863
- Joined: 2004-04-23 10:21
- Contact:
Nir_kornfeld,
Nat router behave total different for UDP and TCP connections.
Using TCP, each connection get his own NAT port.
A(5900)-->router-->7645->B
A(5900)-->router-->5765->C
port is closed on disconnect
But UDP
A(5900)-->router-->5684->B
A(5900)-->router-->5684->C
Udp ports does not get closed on disconnect, they stay 5-10 minutes open after an udp packet goes out
.
Sample:
A=viewer
B=3the PC
C=server
A(5900)-->router-->5684->B
C(5900)-->router-->9875->B
B know the router desination for server and viewer.
C (using 5684)still can not reach A: Blocked by nat router , not in destination table
A (using 9875)still can not reach C: Blocked by nat router , not in destination table
BUT: As soon as A send a package to C and C send a package to A, both routers add A/C in the destination table
The trick is that the router does not know if the packet is an answer to his (blocked) packet or a new package
This behaviour is some IEEE standard for Nat routers.
I would not run a public NH server if all data needed to be routed by my server.....not gonne pay for all that traffic.
PS:
Still need to find time to make the changes for NH and helpers.
First need to finish some commercial proggy (deadline)....Japanese keyboards are a hell to handle .
For now, only some little time to answer posts.
Nat router behave total different for UDP and TCP connections.
Using TCP, each connection get his own NAT port.
A(5900)-->router-->7645->B
A(5900)-->router-->5765->C
port is closed on disconnect
But UDP
A(5900)-->router-->5684->B
A(5900)-->router-->5684->C
Udp ports does not get closed on disconnect, they stay 5-10 minutes open after an udp packet goes out
.
Sample:
A=viewer
B=3the PC
C=server
A(5900)-->router-->5684->B
C(5900)-->router-->9875->B
B know the router desination for server and viewer.
C (using 5684)still can not reach A: Blocked by nat router , not in destination table
A (using 9875)still can not reach C: Blocked by nat router , not in destination table
BUT: As soon as A send a package to C and C send a package to A, both routers add A/C in the destination table
The trick is that the router does not know if the packet is an answer to his (blocked) packet or a new package
This behaviour is some IEEE standard for Nat routers.
I would not run a public NH server if all data needed to be routed by my server.....not gonne pay for all that traffic.
PS:
Still need to find time to make the changes for NH and helpers.
First need to finish some commercial proggy (deadline)....Japanese keyboards are a hell to handle .
For now, only some little time to answer posts.
Sergio wrote:The diference between repeater and NAT2NAT is that the repeater is ALWAYS in the middle of the viewer-server communication, instead NAT2NAT is used ONLY to establish the initial communication, and after that everything works like a Point to Point link between both ends.nir_kornfeld wrote:I don't see how the Nat2Nat will work quicker than the repeater. So if anybody knows the answer, I will be glad to know...
Thanks.
If I'm wrong ... please let me know !!!
HTH
nir_kornfeld wrote:You are wrong.
So ... I'm glad I wasn't wrong at all !Rudi De Vos wrote:Nir_kornfeld,
Nat router behave total different for UDP and TCP connections.
Sample:
A=viewer
B=3the PC
C=server
A(5900)-->router-->5684->B
C(5900)-->router-->9875->B
B know the router desination for server and viewer.
C (using 5684)still can not reach A: Blocked by nat router , not in destination table
A (using 9875)still can not reach C: Blocked by nat router , not in destination table
BUT: As soon as A send a package to C and C send a package to A, both routers add A/C in the destination table
The trick is that the router does not know if the packet is an answer to his (blocked) packet or a new package
This behaviour is some IEEE standard for Nat routers.
I would not run a public NH server if all data needed to be routed by my server.....not gonne pay for all that traffic.
NAT2NAT
From what the Diagram shows this is how I theorize how it works:
It will save alot of bandwith of who ever is holding the NAT2NAT Server .
I do believe it is similar in design as peer to peer sharing . The NAT2NAT
server acts as a Directory Server and Relay at First and help the Client
and server connect to each other .
1) Client and server connect to the NAT2NAT server .
2) The NAT2NAT server recieves from and informs the VNCclient and VNCserver piece what the IP address and port Numbers the Outbound Connections are going to be from.
It takes advantage of the out of order sequence of events and the Fact that UDP is Connectionless and stays open for a specific amount time. Usually 5 minutes.
1) VNCClient: Hey what IP and UDP port is the server operating on? ----> Nat2Nat server
2) Nat2NAt Server -----> Server is on this IP and UDP port
3) VNCServer: Hey What IP and UDP Port is the Client on ----> Nat2Nat server
4) Nat2Nat server ------> Cleint is on this IP and UDP port
5) VNCServer: Hey I am going to send some out bound connection attempts to VNCClient --------> Nat2NAt server
6) NAT2nat server: Hey VNCserver is going to send connection attempts
start sending replies back to VNCserver before he sends requests ---> VNCClient
7) VNCClient : OK I am sending replies to requests before they are sent ---> NAT2NATserver
NAT2NAT : VNCClient is sending replies start sending requests to VNCCleint-----> VNCServer
Eventually Each of the NAT devices that are watching will recieve replies
from one of the requests outbound and connectivity is established between
the 2 NAT devices both of wich see the intial connection coming from inside the private networks .
Once connection is established a series of keep alives is sent and the TCP/IP connection is actually tunnelled through the UDP connection .. similar to a VPN Connection tunnel.
Funny thing I was doing research on how this could be done and the guys here had the same Idea and the programming skills
what is the satus on NAT2NAT
I could REALLLY use it since I work off wireless access points I do not control
[mod=494,1118095221]deleted 2 message was replicate same content[/mod]
I could REALLLY use it since I work off wireless access points I do not control
[mod=494,1118095221]deleted 2 message was replicate same content[/mod]
Last edited by Shaba1 on 2005-06-06 22:00, edited 2 times in total.