This may seem a naive question, since the computer networks knowledge from university days has almost vanished throughout the years, but before getting my hands on a book relevant on this topic, I would like to find out what more experienced folks out there know about this.
Basically I would like to be able to connect a client (C) to a remote server (S), sitting in separate LANs, without adding special rules (e.g. port forwarding) to any of the routers in between.
I know that some applications (TeamViewer) use broker servers for connecting a client to a remote machine, but what I don't know is if the whole traffic between them goes through the broker server.
For my use case, I would use such a server only for initial discovery of the peers (more exactly the discovery of S by C), then the traffic would go through a connection directly initiated by C towards S.
Would such an approach be possible?
Thank you!
Unfortunately if the devices reside in networks separated by the Internet your first hurdle concerns RFC1918. In order to connect to a private IP you will have to use some level of NAT. To over come this is to build a VPN connection between the two networks affectively connecting as if each are local to the other. Please note that to avoid any NAT configuration in this scenario requires that the private networks are using different subnets IPs
Related
I developed a decentralized gaming app, where players connecting to the backend from GUI using websockets. On my test environment my backend nodes have static public IP's, so I'm able to establish the websocket connections and test the game.
I'm planning to release the game to the community to test the game, but it was the case that not many have static IP's to test. So it all boils down to the situation that I feel I messed up with the design at the initial stage in using static IP's for connection b/w GUI and backend.
What I'm looking for the possibility is, say suppose if my machine is connected to the internet, is there a way I can assign some end point address to my machine and I can connect to this end point address using MQTT or any other possible way.
Can you please share your inputs on how can I overcome this problem.
Thank you.
One more important thing you should consider for a decentralized network is that we have many NAT devices(routers) during the Internet. So, we cannot connect to each other as we want to.
You should do something like bt download apps have done. For example, you can have a tracker(centralized controller). If you don't want it, then DHT and LSD is what you must learn. Using these protocols, you can realise your design.
The community needs a static public ip , and all people have one .
The IPs they have are not 1 IP per computer .
Now days since IPV4 addresses are not alot they are using NAT ( Network Address Translation )
so PC's can have all an IP address in common within the same LAN .
so your app will still be usable they IPs will be static , thus the ports used will varey .
you can see more about NAT here :
https://en.wikipedia.org/wiki/Network_address_translation
Two computers in separate NAT networks, wants to connect with each other.
No port forwarding can be made.
We can connect between them using a intermediate server, however we dont want the entire communication to go through this server after the initial connectivity.
Is there any way that the intermediate server can perform the initial connection and then allow them to continue their communication directly somehow ?
Everything I know about computer networks say 'no', however I though I'll give this question a try here.
It can be done vía NAT traversal techniques. It isn't simple but many applications do it, e.g. Skype, where channeling all communication through a server would be innefective.
I have a somewhat basic understanding of network programming (and networking concepts in general) from taking a networking course in university a few years ago.
I remember being able to create a simple chat application, where the chat server is used as a central directory aware of which clients are currently online, but once a client knows another client it wants to chat with, the actual messages between them don't need to go through the server. I remember we could only test this over a bunch of LAN machines.
This C# chat program also has several comments mentioning that the program does not work over the internet: http://www.geekpedia.com/tutorial239_Csharp-Chat-Part-1---Building-the-Chat-Client.html
My question is why do these applications not work over the internet when "commercial" chat applications can. Surely, there is some way to make my computer accessible to the outer network even if its IP address is not valid outside the network of the ISP.
I see no problem with the linked-to code. The server doesn't even bind to a local address, which means it will listen for connections on all ip-addresses on the computer. There is however a comment for in the server article where the user changed the TcpListener object creation to bind to a specific address, which means clients only can connect to that specific address.
In the original server design, with using TcpListenet with only a port number, there should be nothing preventing its use on an Internet connected computer, unless there is a firewall blocking access.
Were you aware of networkComms.net and in particular the short chat example demonstrating the functionality here (It's less than 15 lines of code)? This was written specifically for people writing server-client apps in c# and given most of the problems you might come across will already have been solved and it might save you some time. This library is completely plug & play and has no issues working over the internet (as long as you can setup the necessary port forwarding where necessary).
Generally if both of your targets are behind NAT (so no true external ip addresses) and you are unable to configure port forwarding you need to look at 'TCP / UDP hole punching', quite an advanced technique.
First-timer on Stack Overflow here. I'm surprised nobody seems to have asked this question, and I hope this is the right place to ask this. I'm trying to determine if I should expect regular network switches (just simple switches, not routers) to have the capability to isolate local network traffic (i.e. targeted traffic that is directed to another local port in the ame switch) within the switch?
For example, if I have 2 machines connected to ports on the same switch (say, ports 2 and 3) and conversing using a directed, non-broadcast protocol (e.g. TCP), I wanted to make sure the traffic between these 2 machines are not forwarded the the rest of the network outside of the switched subnet.
I'm building a home network and I wanted to build private network "subnets" or "zones" using switches where local subnet traffic does not get forwarded to the "backbone" or the rest of the network. Note that I am NOT trying to block any inbound or outbound traffic to/from/between these "zones", but I just wanted to implement a "need to know" basis for these zones to limit network-wide exposure for localized traffic destined within the same switch. Specifically, I wanted the backbone to have as little unnecessary traffic as possible.
So back to the original question: is it fair to expect any network switch out there to be smart enough not to forward local traffic to the rest of the network? I would expect this to be the case, but I wanted to make sure.
PS: You can assume I have a DHCP/WINS server somewhere on the network that will be assigning IP addresses and the such.
I hope the question makes sense, and any help will be appreciated!
- K.
Short answer: yes, the switch is smart enough (otherwise it would be a hub).
And if you need fancy stuff you might have a look a VLANs.
And I believe this question belongs to serverfault or maybe superuser. That's probably why nobody asked it here :)
We're implementing a SIP-based solution and have configured the setup to work with RTPProxy. Right now, we're routing everything through RTPProxy as we were having some issues with media transport relying on ICE. If we're not mistaken, a central relay server is necessary for relaying streaming data between two clients if they're behind symmetric NATs. In practice, is this a large percentage of all consumer users? How much bandwidth woudl we save if we implemented proper routing to skip the relay server when not necessary. Are there better solutions we're missing?
In falling order of usefulness:
There is a direct connection between the two endpoints in both directions. You just connect and you are essentially done.
There is a direct connection between the two endpoints in one direction. In that case you just connect via the right direction by trying both.
Both parties are behind NATs of some kind.
Luckily, UPnP works in one end, you can then upgrade the connection to the above scheme
UPnP doesn't work, but STUN does. Use it to punch a hole in the NAT. There are a couple of different protocols but the general trick is to negotiate via a middle man that coordinates the NAT-piercing.
You fall back to let another node on the network act as a relaying proxy.
If you implement the full list above, then you have to give up very few connections and don't have to spend much time on bandwidth utilization at proxies. The BitTorrent protocol, of which I am somewhat familiar, usually stops at UPnP, but provides a built-in test to test for connectivity through the NAT.
One really wonders why IPv6 did not get implemented earlier - this is a waste of programmers time.
Real world NAT types survey (not a huge dataset, though):
http://nattest.net.in.tum.de/results.php
According to Google, about 8% of the traffic has to be relayed: http://code.google.com/apis/talk/libjingle/important_concepts.html
A large percentage (if not the majority) of home users uses NAT, as that is what those xDSL/cable routers use to provide network access to the local network.
You can theoretically use UPnP to open ports and set-up forwarding rules on the router to go through the NAT transparently. Unfortunately (or fortunately, depending on who you are) many users disable UPnP as a matter of course on their router and may not appreciate having to add forwarding rules manually.
What you might be able to do (and what Skype does AFAIK) is to have some of the users that have clear network paths and enough bandwidth act as relay nodes. Apart from the routing and QoS issues, you would at least have to find some way to ensure the privacy of any relayed data from anyone, including the owner of the relay node. In addition, there might be legal issues to settle with this approach, apart from the technical ones.