I have used RMI for the communication. I tested yesterday with the client on Linux and the server on Windows, and when I found out after 3 hours my girlfriend is running some strange firewall, it worked great. Then I tried the other way around, with the server on Linux, and it fails.
The problem is that the server thinks it's running on a machine that has IP address 127.0.1.1 -- which corresponds to the entry with my hostname in the /etc/hosts file.
So this is the IP address it communicates to the client, which tries to connect to this IP and some high port where it's supposed to find the RMI service, which fails.
I can make it work by forcing the RMI server hostname using a property, when I start the server:
where the IP address that I typed is the actual IP address of the Linux PC running the server. This is dynamic (DHCP).
Do I have a problem?
Please take a look here. I think it might be helpful! And if you still have doubts after reading it, please let us know so we can try to help you solving your problem!
And partner, please remember that we are not allowed to use command line properties other than the ones that are mentioned in the specifications ("server" and "alone").
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
posted 11 years ago
Thanks for your answer.
Maybe I should have written more precisely what my problem is -- I read the post you referenced but I don't see how it answers my question.
The problem is that if I run my server on the Linux PC, it's confused over what it's hostname or IP address is. What it uses (127.0.1.1) is only sensible on the machine itself. The question is, can I consider this a problem with the configuration of the the Linux PC (putting the IP address 192.168.1.131 in the /etc/hosts file would solve it, but since it was obtained with DHCP, if I reboot it, I might have to put something else). Or is this something my RMI server should be able to figure out?
I mean -- my RMI server does not figure it out at the moment -- it uses 127.0.1.1 as its IP and when the client, on a different PC, tries to connect to that, it receives a "connection refused" error. I can change the configuration of the Linux PC to solve the problem, but I don't know if my software is sufficiently smart.
Let me see if I got your problem. From the same machine the server is running, you try to connect to it using the IP 127.0.0.1, but when you try to connect to the IP 127.0.0.1 from another machine, you get a "connection refused". Is this it?
...on a different PC, tries to connect to that, it receives a "connection refused" error.
Are you using the server's IP or 127.0.0.1? That is, are you trying to connect to 127.0.0.1 or to the machine where the server is running?
It shouldn't be necessary to edit any file. As soon as you start the server, you should be able to connect to it from any computer in the intranet, without requiring any extra configuration. Maybe there's something wrong with the way you are starting your server, that's why I sent you the link.
Howdy partner. The way clients connect to the RMI server is either by IP or hostname. It depends on how you bind your server when you start it. Suppose you use protocol "rmi://<hostIP>:<port> serverName" then clients MUST use the <hostIP> and given <port> to connect.
For example, you run server and client on the same computer. Using 127.0.0.1 to start server. Now if client config types in "localhost" instead 127.0.0.1 .... it doesn't connect. I tried it.
Also as long the server computer has say a ethernet adapter or able to surf the web, when you get the server IP using InetAddress, it should not return a 127.0.0.1 address. The only situation to get 127.0.0.1 is if the ethernet cable is unplugged, or no network adapter in the server computer (which means client can connect remotely).
Also with RMI I mentioned in my design doc that no firewalls are used and both clients and server are in the same LAN (network domain). That way there shouldn't have connection problem due to wrong config.
The reason I assumed no firewalls is probably beyond the assignment because going through firewalls usually mean that the RMI uses a security manager (for dynamic class loading say) which is not allowed.
K. Tsang CEng MBCS PMP PMI-ACP OCPJEA OCPJP
posted 11 years ago
Thanks all for your answers!
The gest of my problem is the same as this one:
you run server and client on the same computer. Using 127.0.0.1 to start server. Now if client config types in "localhost" instead 127.0.0.1 .... it doesn't connect
localhost and 127.0.0.1 should be equivalent, but they're not... In my case, the server is using what it's thinking are equivalent IP addresses (127.0.1.1 and the IP address it has in the LAN, 192.168.1.131) -- but they're not equivalent if you're connecting from a different machine, so it doesn't work.
K then says:
The only situation to get 127.0.0.1 is if the ethernet cable is unplugged, or no network adapter in the server computer
I don't think we need to deal with these cases, because it's pretty obvious that to connect to the server, the server must be connected to the network. And the power cable must be connected as well. But I have an additional way to get 127.0.0.1 (or actually 127.0.1.1, which is an alternative IP address for localhost). The hostname command returns "paullaptop2". My /etc/hosts file has this line:
The communication goes this way:
Client says to server port 1099 (the registry): Give me RMI service X
Server says: It's on IP N port M
Client says: Connect to IP N port M and access RMI service
The server response "IP N port M" should be the IP of the server on some port that the RMI registry decides. The problem is that the IP of the server on the server itself is 127.0.0.1, which is equivalent to localhost, but of course if you're on a different machine (the client one), localhost is the client machine... Therefore when the client tries to connect to 127.0.0.1 in the last step, this is the machine the client runs on. There is no server there, so it fails to connect.
I think I'm going to add to my design doc that the RMI server must resolve its IP address in a way that is usable by the clients (127.0.0.1 is not, in general). That way I make it a server configuration issue, a prerequisite, so to say. And I'll also add the requirement that there's no firewall, good idea.
Partner, the goal is to connect to the server from a client machine in the same intranet. So, for instance, if you can, from a client machine, connect to the server using its IP address, then there's nothing to worry about.
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
Don't play dumb with me! But you can try this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!