Cannot connect on localhost

For a while now I’ve been just using my IP address rather than localhost or 127.0.0.1, because I can’t connect to this server otherwise. Recently I’ve been looking into this again as I am now trying to get some software from this thread to work (it need me to connect over localhost) But I can’t seem to figure out why. Does anyone know what causes this or where I could start looking? Thanks.

Not really, this should not be, how do you bind your socket? Is it bound to all interfaces?

@Empire Phoenix said: Not really, this should not be, how do you bind your socket? Is it bound to all interfaces?

Umm, what does that mean exactly?

What OS, Java version, JME version, etc.?

Is this specific to Spidermonkey or are you having problems connecting to localhost in general?

If you run the JME tests TestChatServer and TestChatClient does it let you connect to localhost?

As far as I am aware spidermonkey (and any java network connection) binds to adress 0.0.0.0 - which essentially allows a connection to all IP addresses on the local machine including 127.0.0.1 a.k.a “localhost” unless you specifically bind it to an IP address yourself. In my experience it’s unwise (and partially un-necessary) to specifically declare which IP address you want to use, it can really complicate matters if you aren’t very educated about network-related situations.

Windows firewall?

Windows firewall is disabled, The TestClientChat and TestServerChat seem to work fine with localhost, this is the output I get when I try to connect (on my game) with localhost:

Feb 12, 2014 9:19:44 PM com.jme3.network.base.DefaultClient handleError
SEVERE: Termining connection due to unhandled error
com.jme3.network.kernel.ConnectorException: Error reading from connection to:localhost/127.0.0.1:27015
at com.jme3.network.kernel.tcp.SocketConnector.read(SocketConnector.java:134)
at com.jme3.network.base.ConnectorAdapter.run(ConnectorAdapter.java:158)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:189)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
at java.net.SocketInputStream.read(SocketInputStream.java:107)
at com.jme3.network.kernel.tcp.SocketConnector.read(SocketConnector.java:120)
… 1 more

Here is a screen of my router’s firewall settings :

I know as little as possible about networking :slight_smile: its probably either a code related issue or something to do with the port… I think it worked on my old router, as far as I can tell.

If the test chat is working and your app isn’t… then I don’t know what to say.

Figure out how you’ve done your networking differently, I guess. Or see what you have to do to the test chat to break it in a similar way.

@jayfella said: As far as I am aware spidermonkey (and any java network connection) binds to adress 0.0.0.0 - which essentially allows a connection to all IP addresses on the local machine including 127.0.0.1 a.k.a "localhost" unless you specifically bind it to an IP address yourself. In my experience it's unwise (and partially un-necessary) to specifically declare which IP address you want to use, it can really complicate matters if you aren't very educated about network-related situations.

In fact, SpiderMonkey does not (by default) expose anything that would allow you to bind the server to a specific address. You have to do some stuff manually to make that happen and it’s undocumented.

Of course, the client still needs to know what host to contact.

Also note: it’s not your router’s firewall that ever comes into play here. localhost is 100% resolved on the local machine without even touching the ‘over the wire’ networking.

When you disable windows firewall you close all non-default ports and stop play. It doesn’t magically open all ports as one would expect - that would be suicide - and also a very easy hack to utilize should you be that way inclined. Instead, it errs on the side of caution, so have to do it properly. Having said that, try enabling “File and printer sharing”. I’m pretty sure a side-effect of doing that allows all local traffic through.

How is the port established? I’ve never used SpiderMonkey… is this define by the user? Or?

com.jme3.network.kernel.ConnectorException: Error reading from connection to:localhost/127.0.0.1:27015

Assuming that the port is selected by you:

Is your client searching for a the server using this port number? (I assume yes, seeing as this is likely a client thrown error)
Is your server actually setup on this port? << this is sorta important =)

Yeah… I know… really basic stuff… however, it’s always best to ask the obvious before looking for a solution elsewhere. Externally, the server is a service that is likely name referenced and will auto-detect the port the service is running on. Internally, this is not the case (afaik)

Just to summarize the state of things so that I (and everyone else reading) are clear on the facts:

  1. Running the JME SpiderMonkey test Chat Server and Chat Client work when connecting to localhost.

  2. Running your SpiderMonkey based server and client do not work with localhost.

@pspeed said: Just to summarize the state of things so that I (and everyone else reading) are clear on the facts:
  1. Running the JME SpiderMonkey test Chat Server and Chat Client work when connecting to localhost.

  2. Running your SpiderMonkey based server and client do not work with localhost.

Yep… this is why I asked the question about how he set up the server. In your tests the port is defined as static and the client references the port via the server class (no way to muck up the port reference)

In his application, his client might be defining the port the server is running on improperly?? Possibly, anyways.

Still… good to mention the fact that the test works.

@t0neg0d said: Yep... this is why I asked the question about how he set up the server. In your tests the port is defined as static and the client references the port via the server class (no way to muck up the port reference)

In his application, his client might be defining the port the server is running on improperly?? Possibly, anyways.

Still… good to mention the fact that the test works.

The server port has to be static. It’s the minimum thing you have to provide when creating a server. If you try to connect a client using a different port then you should get a different error. (Connection refused versus connection reset for example.)

…and anyway, you must specify a port for connecting the client, too. Presumably the OP didn’t plug some strange value in for that.

Then I have another super stupid question for the OP:

If this runs using a live IP, why be concerned about using localhost? It’s obviously not a code related issue, or your server/client wouldn’t work at all… meaning that is a configuration issue with you machine.

Guess the question is, why waste your time trying to get this to work locally when you have it working otherwise?

@t0neg0d said: Then I have another super stupid question for the OP:

If this runs using a live IP, why be concerned about using localhost? It’s obviously not a code related issue, or your server/client wouldn’t work at all… meaning that is a configuration issue with you machine.

Guess the question is, why waste your time trying to get this to work locally when you have it working otherwise?

Sort of stated earlier: he’s trying to run some network degradation test using a third party tool that requires him to use localhost.

@pspeed said: Sort of stated earlier: he's trying to run some network degradation test using a third party tool that requires him to use localhost.

I take it the source isn’t available to change from local host then =(

@t0neg0d said: I take it the source isn't available to change from local host then =(

My guess is that it’s a technical issue involving where they inject themselves into the TCP/IP stack.

:roll: Yess T0neG0d I did check they were on the same port :slight_smile: I’ve figured out that its the port I was using, I tried using 27015 for the test chat and it didn’t work, and I’ve tried using 5110 ( the one test chat was using) For the game, and it works… This is a solution to the problem, but its also very odd and I can’t think why that port would work over 27015?