Java套接字端口转发

Question

I made a networked game in Java using Sockets. It works great, except... only through my LAN. :/ What I want to be able to do is set it up so that I can start the server running on my home computer and send the client code, in an executable jar, to someone else, and have them be able to launch it and connect through the internet. But like... I have no idea how to set up my modem & router for that. :( I have a wireless Clear modem, for which the configuration page looks like this:

http://imageshack.us/photo/my-images/254/modem.jpg

And a Netgear router, whose page looks like this:

http://imageshack.us/photo/my-images/443/routerq.jpg

Right now, in the client and server runner classes, I pass my PC's private IP address along with my chosen port number to the ServerSocket and Socket objects. I hear that Sockets are able to be either UDP or TCP, depending on how you set them up, or something...? I don't do anything like that though, I just instantiate them and pass them the 2 values, and off they go...

In the code for the server:

ServerSocket sock = new ServerSocket();
sock.bind(new InetSocketAddress(IP, 9001));

Code for the client:

Socket sock = new Socket(IP, 9001);

So also, I would need to know how to change the code accordingly with the changes to my router/modem settings.

"IP" is a String representing my computer's private IP, 192.168.1.10, and the program only works if that is the string I pass to the Socket & ServerSocket. Like I said, I have a modem which is connected to a router which is connected to my computer. So, can someone please explain to me (in detail, because I'm a noob) what exactly I would have to do to configure both of them, AND the changes I would have to make to my code?

Answer 1

You'll have to manually port forward, or look at a solution like UPnP or NAT-PMP for automatic port forwarding. Unfortunately, NAT is a pain in the ass to configure and most routers don't properly support it. It's also not a simple task, as you have to support a whole range of different implementations and mechanisms.

It shouldn't be too difficult to set up your router to forward one port to your machine, though. See http://portforward.com/ for an awesome list of how to do it on pretty much any router.

Answer 2

It sounds like you're asking a number of questions here... I'm no network/socket programming specialist, but here's some ideas.

For distribution, you may wish to look into Java Web Start . It'll make it easy for your clients to obtain the app as well as automating updates.

If you're using the Socket constructor like that, the actual implementation will be a system default. You could override this by calling this method with a suitable SocketImplFactory implementation.

As for the IP address and port... Using a hard-coded value for the port should be okay. You'll need to decide on a port or at least some default anyway for clients to connect to. Even so, it might be useful to have the value read from some external configuration file. This'll make it easier should you ever decide to distribute the server app to let other people run servers. They might want to use a different port.

Having the server's IP address (yours) hard-coded in code is definitely a no-no, though. Clients should connect using either an IP address or host name that they need to provide or set in some configuration file. A host name would be required if you don't have a static IP address.

Unless this is something for you and some friends to enjoy, where you can always just initiate a game by providing IP and port in a chat session or something, you'd be better off finding some external hosting solution at a company that takes care of the DNS resolution and network setup for you. These days you'll find stuff like that pretty cheap if you don't have requirements like a Java EE server or database.

EDIT: thought of something else. TCP might be okay for your use-case, but if this is a game that requires minimal lag and quick input synchronization (like a shooter or fighting game) then it's not the best choice. In that case UDP would be better. It would induce the requirement of adding some sort of detection for desync or a mechanism that makes up for any dropped packets.