 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / September 2006RMI thru Internet
Hello everybody, Im using RMI to connect java applet with a remote server. The connection is successful when the server in same machine or in the same flat network but its failed when try to establish connection through the Internet. The connection is simply established thru this line: LocateRegistry.getRegistry(getCodeBase().getHost(), RemoteInterface.REGISTRY_PORT); remoteReference = (RemoteInterface) registry.lookup("//222.222.222.222/MyFolder"+RemoteInterface.REGISTRY_NAME); do to I have to improve the rmi code by some way or use different tool to establish the connection thru Internet. .... > Im using RMI to connect java applet with a remote server. The > connection > is successful when the server in same machine or in the same flat > network > but its failed How? Security exception? sand-box - sign it. > do to I have to improve the rmi code by some way or use different tool > to establish the connection thru Internet. Improving the error output might help.. Andrew T. > .... > > Im using RMI to connect java applet with a remote server. The [quoted text clipped - 4 lines] > > How? Security exception? sand-box - sign it. I think the application looks for IP address that inside the same local network directly. It can't traverse the internet getways. I got this error from the browser java console: java.lang.RuntimeException: java.rmi.ConnectException: Connection refused to host: 222.222.222.222; nested exception is: java.net.ConnectException: Connection timed out: connect at ClientApplet.init(ClientApplet.java:29) at sun.applet.AppletPanel.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.rmi.ConnectException: Connection refused to host: 222.222.222.222; nested exception is: java.net.ConnectException: Connection timed out: connect at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source) at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown Source) at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown Source) at sun.rmi.server.UnicastRef.newCall(Unknown Source) at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source) at ClientApplet.init(ClientApplet.java:24) ... 2 more Caused by: java.net.ConnectException: Connection timed out: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.<init>(Unknown Source) at java.net.Socket.<init>(Unknown Source) at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(Unknown Source) at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(Unknown Source) ... 8 more I replaced the real IP with 222.222.222.222 > > do to I have to improve the rmi code by some way or use different tool > > to establish the connection thru Internet. > > Improving the error output might help.. > > Andrew T. >> .... >> > Im using RMI to connect java applet with a remote server. The [quoted text clipped - 42 lines] > > I replaced the real IP with 222.222.222.222 This sounds like a network problem rather than a Java one. Have you tried the basic tests, e.g. manually pinging the server? - Oliver > This sounds like a network problem rather than a Java one. Have you > tried the basic tests, e.g. manually pinging the server? no oliver the web server is running correctly. In fact i can see the other content of page like the text but the applet can't contact the remote object which is declared in the registry in the same web server through the Internet. > - Oliver >> This sounds like a network problem rather than a Java one. Have you >> tried the basic tests, e.g. manually pinging the server? >> > no oliver the web server is running correctly. I'm very confused by your reply. "No", you didn't test, and yet you're sure everything is configured correctly? > In fact i can see the > other > content of page like the text Yes, but can you see whatever server your applet is trying to connect to from the machine on which the applet is failing? > but the applet can't contact the remote > object which is declared in the registry in the same web server > through the Internet. What registry are you talking about? - Oliver >> This sounds like a network problem rather than a Java one. Have you >> tried the basic tests, e.g. manually pinging the server? [quoted text clipped - 6 lines] > >> - Oliver Does the web server have a firewall, or are there other firewalls in the path? Do they allow you to contact the RMI registry on the default port of 1099? The "connection timed out" shows that your attempt to connect to the RMI server has failed. The fact that the server is running and the connection timed out indicates that the packets were dropped. The normal response would be that the connection was reset immediately if nothing was listening on the port and no firewall was present. This would tend to indicate the actions of a poorly configured firewall (i.e. dropping rather than rejecting packets). There are other reasons why it might happen, but a firewall is the most likely.  SignatureNigel Wade, System Administrator, Space Plasma Physics Group, University of Leicester, Leicester, LE1 7RH, UK E-mail : nmw@ion.le.ac.uk Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555 > This would tend to indicate the actions of a poorly > configured firewall (i.e. dropping rather than rejecting packets). Not necessarily. There's an argument that says that a firewall that's really trying to protect an inner resource should behave as though the resource doesn't even exist, as in this case. > There are > other reasons why it might happen, but a firewall is the most likely. Agreed >> This would tend to indicate the actions of a poorly >> configured firewall (i.e. dropping rather than rejecting packets). > > Not necessarily. There's an argument that says that a firewall that's > really trying to protect an inner resource should behave as though the > resource doesn't even exist, as in this case. It's a bad argument. If a firewall on a web server drops packets the firewall is *not* behaving as if the web server did not exist. The idea that "stealth" mode is somehow magically proving extra security for your system is wrong and is most often propagated by misinformed web sites, the most infamous being GRCs website. If I attempt to verify the existence of a system and the packets are dropped I can be fairly certain that something is hiding the system. If the system simply didn't exist I would almost certainly receive an ICMP host unreachable from the upstream router. Doing basic route tracing to find where the packets are dropped may tell me more. If the packets are dropped at a border firewall I can't discover much. However, if they are dropped at the host by a software firewall I know the system exists, that it's up and running and is "protected" by a firewall which was most likely setup by someone who doesn't really understand what they are doing - i.e. a target well worth further investigation. Configuring the host firewall to return ICMP host unreachable, or RST, would provide exactly the same level of protection, would be much more polite and would not break standard networking protocols. SignatureNigel Wade, System Administrator, Space Plasma Physics Group, University of Leicester, Leicester, LE1 7RH, UK E-mail : nmw@ion.le.ac.uk Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555 > It's a bad argument. Quite possibly, but there are existing products that do it, so you have to cope. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.