Incredibly weird Connection Refused error

Troubleshooting networking
1 
if (FriendFunctions.serverIsLookingForClient(name)) {
			try {
				String ip = LoginFunctions.getOtherIP(name);
				System.out.println("other: " + ip);
				if (ip.equals(BasicFunctions.getIpv4()))
					ip = "127.0.0.1";
				Main.myClient = Network.connectToServer(ip, 8972);
				Main.myClient.start();
			} catch (IOException ex) {
				Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
			}
			this.switchStates(new OnlineClientCharacterSelectState(new RequestFriend()));
		} else {
			try {
				Main.myServer = Network.createServer(8972);
				Main.myServer.start();
			} catch (IOException ex) {
				Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
			}
			FriendFunctions.lookForClient(name);
			this.switchStates(new OnlineServerCharacterSelectState(new RequestFriend()));
		}

The above is my code for a server and client to connect with each other.

When running two copies of the app from Eclipse, it works perfectly- regardless of which copy is the server and which is the client.

I exported my app to a jar, and ran the app both using the jar and using Eclipse. Again, it works perfectly, no matter which is the server and which is the client.

Then I transferred the jar over to another machine (on the same network), and tested using that and the version on the original machine using Eclipse.

Here’s where things get weird. If the jar version on the other machine is the server, the Eclipse version connects as a client perfectly. If the Eclipse version is the server, however, attempting to connect using the jar version causes a Connection Refused error.

The FriendFunctions, LoginFunctions, and BasicFunctions stuff are functions for my FTP site and are all working properly- that is to say, the IP gotten by the soon-to-be client is the one used by the server to log into the site. There is no chance of this being incorrect.

So without the IP address being incorrect, how could this happen? How would being on separate machines affect the client side for one but not the other?

(Through testing, I have determined that the server is up and running by the time the client tries to connect, so that isn’t the issue either)

2

Off the top of my head I’d be trying a lower port than 8972. Try something basic like 80 (I know that’s for web servers and all but give it a whirl). The lower ports on most machines are usually open by default. The higher end ones are sometimes blocked by default (not knowing what OS you’re running these on does make this a bit difficult).

Onnnnnnnnnnnnnnne other thing I’d like to toss on out there for you as a tip. Don’t use FTP. If you absolutely must use FTP consider SFTP instead. FTP is crazy insecure. Makes the Security Admin in my cringe. You could also consider SCP as well.

1 Like
3

I’m running on Mac OSX, Sierra for both machines.

When I tried 80, it threw a KernelException:

com.jme3.network.kernel.KernelException: Error hosting:0.0.0.0/0.0.0.0:80

This also happened for other low numbers I tried (I tried a few near 100).

(Also, the FTP is a temporary measure. Once I get this stuff working, I’m planning on switching to a more secure matchmaking system)

4

Its called well known ports on unix. Everything < 1024 needs root permissions to bind

5

I’m sure this is well intentioned but basically wrong.
a) as mentioned, lower ports are often blocked by the OS without root permissions.
b) if an upper port was the problem then the server wouldn’t start
c) higher ports are fine and are never blocked… after all, up high enough, this is where the ephemeral ports are pulled from when you create a connection.

This is not his issue. It could be an OS permission thing that is different between the different executables. Hard to say.

This is right, though. Generally FTP is insecure but that’s a FTP server implementation issue almost as much as anything else. Best avoided in any case as there are way better technologies.

1 Like
6

Here I was all ready to argue the port thing with ya when I decided to look it up.

No surprise that you’re right. :stuck_out_tongue: I got my ranges flipped in my head I guess.

Interestingly though is that depending on the OS and version of the OS it can be different.

7

So what sort of OS permission thing would let you create a server, but not connect to it? And why would it only be present in the jar version? Is there something Eclipse does automatically to open up the machine more?

8

One is being run as a child of whatever.exe and the other is being run as a child of java.exe or javaw.exe…

or whatever the equivalent is in your OS.

The point is “the only thing that’s different” is the only thing that can cause it. So then you trace into what makes that difference different. Beyond that, I cannot help you.

1 Like