|
I see you wrote this article: NAT Traversal with UPnP in C#[^], so maybe I don't understand your question, but here goes anyway:
If your clients are behind a NAT device, it is better not to initiate a connection from your server - get the clients to make the connections.
As for getting the public ip:port - it will be the one the server sees as the source of the connection attempt. The NAT device handles ( and hides ) the private network.
Nick
----------------------------------
Be excellent to each other 
|
|
|
|
|
Ah well, the problem is, the server doesn't see the right thing. It sees a random port that was assigned to the socket by windows and trying to bind to prevent that results in inability to connect at all..
|
|
|
|
|
So, your server trying to initiate a connection to a client that is behind a NAT device? This is difficult.
Can't you get the clients to connect to the server? You can leave the connection open if you want the server to initiate data transfer over the connection. Or your clients can poll the server. It depends on what Application Layer protocol you're using.
Nick
----------------------------------
Be excellent to each other
|
|
|
|
|
Well yes sortof, the client would be trying to connect to an other client but that's pretty much equivalent (in regard to the NAT problem) to having the server do it.
The server is just supposed to store the addresses+ports of the clients so they can find eachother
A bit like bittorrent, but different (but it does mean that bittorrent clients have already solved this public port problem so it can't be impossible)
|
|
|
|
|
I'm not sure how bittorrent works, but most P2P networks nominate a peer that is not behind a NAT ( and can therefore be connected to ) to act as a server for a client that is behind a NAT. That's how Skype works - or at least used to work.
Generally, connecting to a client that is behind a NAT is too difficult and unreliable to be used in the design of a P2P network.
Ah, a bit of googling found this: http://www.codeproject.com/Messages/3001183/NAT-Traversal-in-Csharp-P2P-behind-firewalls-NAT-Routers-UDP-Hole-Punching.aspx[^]. Are you still trying to help this guy?
Nick
----------------------------------
Be excellent to each other
|
|
|
|
|
Bittorrent uses servers to store the clients' details (potentially these could be clients themselves, but usually not)
I'm afraid I'm not trying to help him anymore, I got lost in the woods of symmetric NAT and other crazy stuff for which there appears to be no solution at all.. they should never have invented NAT, it's a bad hack anyway 
|
|
|
|
|
Hi Harold,
In a c/s situation the initiative is with the client.
servers shouldn't connect to clients at all if you ask me. That would be spamming.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Oh yes no that is not what it's trying to do - it's storing their address+port so that other clients can connect to clients directly (which is where all the trouble comes from really)
So the clients then go into P2P mode.. and they'll have to do that because otherwise the load on the server would be enormous
I guess I should have mentioned that lol
|
|
|
|
|
You real problem in that, from the server side, the clients NAT/Firewalls are going to deny all inbound connections anyway. The clients would have to open a well-known port on their end (firewall) to let other clients connect to them.
|
|
|
|
|
Yes but this presents a problem, the NAT device could choose to give the forwarded port an other public port because the regular one was already in use (others just error) how could I find out which?
|
|
|
|
|
The internet side of the NAT would open a single, well-known, port and forward that port to a well-known port your app is exposing. What you're talking about is the OUTBOUND port from your client to the server. THAT one gets a random port, not the inbound side.
|
|
|
|
|
Well that is part of the problem, the server can't just use socket.RemoteEndPoint because it's random
|
|
|
|
|
OK, you're not getting it...
The server doesn't need the port number at all since the clients receiving port number will be the same on every instance of the client. This is the "well-known" part. For example, SMTPs well-known port is 25.
But, since the NAT can do port forwarding, the port number the NAT exposes on the internet side can be different than the port exposed by the client to receive connections. The NAT needs to know what IP and port to send the traffic on that port to on the inside network.
|
|
|
|
|
So, I'm still confused, why am I not getting it? There is not any kind of guarantee that the port is "well known" at all, that would only work if only 1 thing on the other side of the NAT would forward that port
|
|
|
|
|
OK. Your client connects to the server to report itself, right? The port number that the client uses will NOT be the port number that it uses to listen for other clients connecting to it. The port number that the server sees the client using is only temporary and only good for that one connection. It the client contacts the server tomorrow to report itself, it'll probably use a different port number. You cannot use this port number for anything useful. The only important part is the server can learn the Internet visible IP address of the client. That's it.
Now, in order for the client to listen for connections from other clients, it has to open a specific "well-known" port to listen for connections on. What makes this "well-known"?? YOU! You pick the port number that your app is going to use to listen for connections. This is going to be a standardized port number that every client is going to listen on.
Great! Now you've got a port number. Well, your client software has a port number. The user's NAT doesn't know that. So, the NAT has to be configured to forward incomming connections from the public internet to a specific IP and port number on the inside of the network, preferrably the client machine(!), and the port that the client is listening on.
Now, back up a second. The NAT can forward any port number exposed to the public internet to any port number on the inside network. So, you can easily have the NAT listening for a different port number on the public internet, but usually you don't want to do this. Normally, you'd just use the same port number that the client is listening for. Just keep it in mind for troubleshooting purposes.
So, now you've got the NAT listening on your well-known port and forward traffic on that port to the client inside the network. Now, another client starts up, contacts the server to report in and get the list of currently connected clients. Your new client attempts to connect to another client, using the IP address it got from the server and the well-known port number. That request is going to get forwarded to the first client by the NAT, and any response sent back to the new client.
Now, if your clients are only supporting a single connection, you can leave it at this. If your clients are going to be able to talk to multiple clients simultaneously, you'd use this initial connection to negotiate with the calling client a second connection on a different port. The new clinet would have to start a listener on a random port, telling the first client which port that is on the initial connection port. The first client would then open a connection back to the new client to start the communication channel the two clients are going to use to chat with. The initial connection can then be closed down and the first client can then reuse the same port to listen for another connection request...
|
|
|
|
|
Ok, but what will happen if more than 1 client is on the same NAT?
|
|
|
|
|
With the communication model you've chosen, you can only have 1 client behind the NAT, unless the NAT sits behind more than 1 IP address.
|
|
|
|
|
Ok, but that is bad.. and bittorrent definitely allows this, and they'd basically have the same problem. Now, I know they send the port number to the server as part of the protocol. Is that why it works? Allowing the port to be manually configured and then send it to the server? Because that's definitely something I could do
|
|
|
|
|
Guy, read up on how servers work first. Just keep 2 things in mind. Your "client" software is really two pieces - a client AND a server listening for connections. The server side is ALWAYS listening on a well-known port and this channel is used to setup negotiated ports for further communication. All you have to do to find this out is run other client/server software under a network sniffer to find this out. But, that itself requires an in-depth knowledge of how TCP/IP and client/server communication works.
|
|
|
|
|
Am I really that stupid? I know how it works normally, I'm just getting thrown off by NAT..
If one could forward the same port twice then I wouldn't have any problem but you can't - making the port unknown.
So in order to hack around that, I thought I could bind to the port (the one that will be listening later) for the outgoing connection so that the server could read the correct port. The documentation of bind suggests that that is possible, but it's not (but from what I know from TCP/IP, it should be). So the only way that I see to get around it is to manually configure the ports for all clients behind the same NAT and send the port number to the server.
|
|
|
|
|
|
yea well ok I guess I deserved that, thanks for your help, I'll go re-read my books on networking
|
|
|
|
|
Dave Kreskowiak wrote: The new clinet would have to start a listener on a random port, telling the first client which port that is on the initial connection port. The first client would then open a connection back to the new client to start the communication channel
Won't NAT block that, if you have only setup port forwarding for the well known client port?
Great response, BTW. +5.
|
|
|
|
|
Well, you'd have to tell the NAT to allow that port also. I think they use UPnP for that if I'm not mistaken.
|
|
|
|
|
Ok, well, I think I've heard enough - I will just accept that it sometimes fails. Not ideal, but, well, NAT is not ideal itself (crazy hack..)
Thanks everyone
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
