Server UDP and port binding

1
votes

I am writing this game in Java and have problems with networking architecture.

I decided I will UDP packets. I am just at the beginning, but the problem I am facing is that it seems to be that server have to respond from exactly same IP/Port to client (which is behind router which uses NAT) as client connected that server.

For example I have client A behind router. Client A has IP (local) 192.168.8.100 and it connects server B from port 1234. Server is on 11.11.11.11:2345.

When client A connects to server B it uses 192.168.8.100:1234 but router converts that to (for example) 22.22.22.22:6789.

Now, when server wants to send packets to that client it has to be from 11.11.11.11:2345. I would like to send data from another port like 11.11.11.11:2222, but this does not seem to work, at least not with my router.

I want to use different port because I want to have two threads one for listening and one for sending data, and each thread would have it's own DatagramSocket. But, as i said once client A connects to server on port 2345, I can not send data from port 2222.

Does anyone know how is this handled? I am doing it in Java, but it's not really a language specific problem.

UPDATE

After @Perception commented I have some more questions regarding his comments:

OK, so if I understand this correctly, if I have server which is hosting 1000 games, each with 2 players, all sending/receiving will have to be done through the same DatagramSocket.

As I understand DatagramSocket is thread safe so I guess I can have one thread doing:

datagramSocket.receive();

while at the same time second thread is doing 

datagramSocket.send(.....);

Correct?

Also, two threads can send data at the same time through the same DatagramSocket? Is sending in any way serialized, meaning that second send() starts only after previous send() is finished or is data being sent at the same time?

2
javanetworkingudp
Not sure this is possible. Your router won't have a mapped entry for the combination of client IP and port you are trying to send to from the server. Because entries are created on the router for outgoing client requests (not incoming server ones). One (possible) solution is to open both comm channels from the client (would require a two-phase handshake between client/server). – Perception
As @Perception says, you can't... At least not with your router. With Linux you could, but this requires you to write an iptables helper (like there exists for FTP: you can use passive FTP from behind a Linux firewall thanks to ip_conntrack_ftp and ip_nat_ftp) – fge
@Perception: Just to make it clear, since from what you wrote it seems you misunderstood it, or I didn't explain good enough. Client connects (initiates requests)from IP1:port1 to server IP2:port2, I want to access client (still IP1:port1) back from server IP2:port3. – gorann
@gorann - Yes I understand what you are trying to do. Please read my comment again, the problem is that your router won't map an incoming request from the server, that was not initiated by the client. – Perception
Show some more code. You're probably connect()ing a datagram socket, don't do that with datagram sockets, that's what requires the ports to be the same. just bind() and send/receive. – nos

2 Answers

0
votes

gorann, I'm not sure if I'm understanding you correctly, but it sounds like you're trying to control the port on which the server communicates with the client. There's no way to control this, and for good reasons.

0
votes

This is one of the trickier differences between TCP and UDP.

When a new TCP session is initiated, the server side call to accept() gives you a new socket and the OS handles multiplexing the various sessions for you. With UDP, you need to handle the multiplexing yourself. But you need to do so in a way that works with NATs and other firewalls.

The way NAT works is that when it sees an outgoing packet, it creates a temporary rule allow packets to return along the same port pair. Data returning from a port that the client has not yet sent to will likely be blocked.

This gives you two choices:

  1. You could do all of your communication through a single port. This is not a bad option, it just means that you need a way to identify client sessions and route them to the appropriate thread.

  2. You could create a separate port and instruct the client to send to that one instead. Have the server listen on a fixed port. The client sends a message to there, the server then sets up a new session port and sends that number back to the client using the server's listen port. The client then sends a message to the session port, which causes the NAT to open up that port and allow return traffic. Now the client and server thread have their own private port pair.

Option 1 is a bit more work because it requires data to be exchanged between threads, but it scales up better. Option 1 is easier and more CPU efficient because each session thread can be independent, but there are a finite number of ports available.

Either way, I recommend that you have the client include a semi-unique session id in each packet so that the server has more than just the client address and port number to verify who belongs to each session.