 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / September 2006RMI port on client side
Hi, We run an application using RMI. We run the RMI registry on server side on port 4000. When a client gets a connection to the server, it appears that RMI also tries to open a connection from server to client on a random port on client side. Because we work in a secured environment, we cannot accept having the client with all ports open; we need to force the server get a connection on client on a predefined port, say 4000. 1) Why does the server need this connection to the client? 3) Can we avoid it? 2) How can we get this connection on a predefined client port. Martin. > We run an application using RMI. > We run the RMI registry on server side on port 4000. > When a client gets a connection to the server, it appears that RMI also > tries to open a connection from server to client on a random port on > client side. That would imply that RMI has first opened a listening port at the client. Can you see it with netstat? RMI only does this at the client if you have a client-side callback in your system and export it, and the reverse connection will only come into existence when the server tries to call the callback. Otherwise all the communication is from RMI client as TCP client to RMI server as TCP server. The extra connection you are seeing could be a DGC connection from the client to the server, or the client to the Registry. Hi, Yes we saw the attempt from the server to get a connection to the client. At the beginning the client could not get a connection with the server whereas port 4000 was open for TCP on server side; so we used a tool (probably netstat) to analyse the network connections and we saw that the connection client->server was ok, but the server was also trying to open a connection server->client which could not work because no port was opened on client side. The RMI interface bound by the server does not define any method providing a client object that could be called back by the server, so I don't understand this connection server->client. Methods only return an object ServerReport that is shared by both server and client. Note that no RMI download mecanism is implemented: classes used by the RMI interface are provided on both sides client & server. EJP a écrit : > > We run an application using RMI. > > We run the RMI registry on server side on port 4000. [quoted text clipped - 11 lines] > The extra connection you are seeing could be a DGC connection from the > client to the server, or the client to the Registry. > At the beginning the client could not get a connection with the server > whereas port 4000 was open for TCP on server side; so we used a tool > (probably netstat) to analyse the network connections and we saw that > the connection client->server was ok, but the server was also trying to > open a connection server->client which could not work because no port > was opened on client side. Are you sure it wasn't trying to connect server->registry? The server will do that for DGC purposes on the Registry stub. Otherwise, i.e. if it really was server->client, I have a hard time believing this is coming from RMI, and I would question the observation actually. Hi, I'm back to this problem which is not yet solved: Server is establishing a connection to RMI client on a random port, whereas RMI interface bound by the server does not define any way for the server to callback the client. I'm providing here after the output produced by netstat executed every seconds on server side. The actual server and client machine names have been replaced by 'server' and 'client'. Port 4000 is used for this RMI connection. When client starts, 2 connections are established: - on port 4000: normal - on port 33041: ABNORMAL: another tool showed that it was a connection server->client >>>>>> This extra connection is NOT IDENTIFIED and NOT WELLCOME<<<<<<<< Can someone explain that??? Thanks a lot. Herve. ================================================================ 1) Netstat output ACTION: Server start 12:35:32 tcp 0 0 server:33043 server:33041 ESTABLISHED tcp 0 0 server:33041 server:33043 ESTABLISHED from 12:35:47 tcp 0 0 server:33043 server:33041 TIME_WAIT from 12:36:47 No trace ACTION: client start 12:38:32 tcp 0 0 server:4000 client:3676 ESTABLISHED tcp 0 0 server:33041 client:3677 ESTABLISHED from 12:39:01 tcp 0 0 server:33041 client:3677 ESTABLISHED ACTION: client stop No trace ACTION: client restart 12:41:53 tcp 0 0 server:4000 client:3682 ESTABLISHED tcp 0 0 server:33041 client:3683 ESTABLISHED from 12:42:23 tcp 0 0 server:33041 client:3683 ESTABLISHED ACTION: client stop Pas de trace ACTION: server restart 12:45:17 tcp 0 0 server:33054 server:33052 ESTABLISHED tcp 0 0 server:33052 server:33054 ESTABLISHED ACTION: client start 12:45:25 tcp 0 0 server:4000 client:3688 ESTABLISHED tcp 0 0 server:33054 server:33052 ESTABLISHED tcp 0 0 server:33052 server:33054 ESTABLISHED tcp 0 0 server:33052 client:3689 ESTABLISHED 12:45:32 tcp 0 0 server:4000 client:3688 ESTABLISHED tcp 0 0 server:33054 server:33052 TIME_WAIT tcp 0 0 server:33052 client:3689 ESTABLISHED 12:45:55 tcp 0 0 server:33054 server:33052 TIME_WAIT tcp 0 0 server:33052 client:3689 ESTABLISHED 2) What the client does: while (true) { remoteServer.call(); Thread.sleep(1000); } 3) What the server does: public void call() throws RemoteException { System.out.println ("I'm called!!"); try {Thread.sleep(1000);}catch(Exception e){}; System.out.println ("Out"); } EJP a écrit : > > At the beginning the client could not get a connection with the server > > whereas port 4000 was open for TCP on server side; so we used a tool [quoted text clipped - 7 lines] > it really was server->client, I have a hard time believing this is > coming from RMI, and I would question the observation actually. > Hi, > I'm back to this problem which is not yet solved: > Server is establishing a connection to RMI client on a random port, > whereas RMI interface bound by the server does not define any way for > the server to callback the client. I think you'll find that it's the other way around, the client has established that connection to the server. I think that RMI works on a very similar principle to RPC. The idea is both cases is that servers shouldn't need to operate on well-defined service ports (these are limited in number, and require global registration), they can listen on any available port and a registry will translate between a service and its listening port. In the case of RMI the registry is rmiregistry, in the case of RPC its portmap. The only port which needs to be determined in advance is the port on which the registry listens. An RMI server must register itself with rmiregisty and tell the registry which port it is listening on. When a client wants to use a service it doesn't initially know where that service is available (the servers listening port). So it asks the registry for a particular service, and the registry will tell it what port that service is available on. The client then contacts the service directly on its listening port. So, the RMI registry is listening on port 4000 and your RMI server is listening on port 33041. Your RMI client contacts the RMI registry on port 4000 and asks where the service it wants can be contacted and is told that it is available on port 33041. The client then contacts the server on port 33041 and invokes whichever remote method it wanted. There will be 2 established connections from the client to the server, to port 4000 for the rmiregistry and to port 33041 to the RMI server itself. [This is my vague understanding, if this is complete bunkum then I apologise in advance...]  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 > I think you'll find that it's the other way around, the client has established > that connection to the server. Agreed. There's no evidence in this server-side netstat dump that it's server->client. I would need to see 33041 LISTENING in a client-side netstat to believe that. And even if it is server->client I still don't believe it's RMI causing it. > [This is my vague understanding, if this is complete bunkum then I apologise in > advance...] @Nigel, this is all quite correct. @OP: if you want to use just port 4000 you have to do two things: (a) start the Registry from within the server JVM using LocateRegistry.createRegistry(4000) (b) export all his RMI server objects on port 4000. As long as the server socket factories are all null or equal according to their Object.equals() method this will work. Thanks to you both for your answers! I have several questions from what you said: 1- connection client/rmiregistry is on port 4000, but what determines the port used for connection client/server_application? Is it necessarily the same, the port used by the client for looking up (4000)? 2- what is the difference between starting the rmiregistry with 'rmiregistry 4000' in a separate shell window and starting it, as you say, from within the server JVM using LocateRegistry.createRegistry(4000) 3- I didn' know that the export of server object with the 'bind' command could be parametrized with a port number. If this port number is not given (my case) what is the default behaviour? 4- I'm not aware at all of what you talk about server socket factories: 'As long as the server socket factories are all null or equal according to their Object.equals() method method this will work' Where are these factories defined, how do I access them, and get their state? About connection direction: It is not netstat which indicates the direction of the connection, as you can imagine from the dump, buth my client uses what he calls 'access list' to monitor the connections between servers of the platform; from this access list system they got the direction of the connection, but I'll get more information about that. Thanks again for your help. Herve. EJP a écrit : > > I think you'll find that it's the other way around, the client has established > > that connection to the server. [quoted text clipped - 18 lines] > As long as the server socket factories are all null or equal according > to their Object.equals() method this will work. > I have several questions from what you said: > 1- connection client/rmiregistry is on port 4000, but what determines > the port used for connection client/server_application? Is it > necessarily the same, the port used by the client for looking up > (4000)? 1.1 If you specify a non-zero port to UnicastRemoteObject.super() or UnicastRemoteObject.exportObject() when exporting your remote object, it will use that port. 1.2 If you specify zero and there is already a remote object (such as the Registry) running inside the JVM with compatible or null server socket factories, it will reuse that port. 1.3. Otherwise RMI will tell the system to choose an arbitary port number, exactly as for new ServerSocket(0) or ServerSocket.bind(null). > 2- what is the difference between starting the rmiregistry with > 'rmiregistry 4000' in a separate shell window and starting it, as you > say, from within the server JVM using > LocateRegistry.createRegistry(4000) If it's inside the server JVM, it has the JVM's classpath; it can be unexported; and it dies with the JVM. Apart from that, no difference at all. BTW why are you using port 4000 for the Registry? Port 1099 is reserved for the RMI Registry by IANA: you should be able to use that. > 3- I didn' know that the export of server object with the 'bind' > command could be parametrized with a port number. If this port number > is not given (my case) what is the default behaviour? See 1.x above. > 4- I'm not aware at all of what you talk about server socket factories: > 'As long as the server socket factories are all null or equal according > to their Object.equals() method method this will work' > Where are these factories defined, how do I access them, and get their > state? See java.rmi.server.RMIServerSocketFactory. If you don't specify these yourself, they are all null and therefore equal & compatible as per 1.x above, and you can ignore this qualification completely. > About connection direction: > It is not netstat which indicates the direction of the connection, as > you can imagine from the dump, buth my client uses what he calls > 'access list' to monitor the connections between servers of the > platform; from this access list system they got the direction of the > connection, but I'll get more information about that. Get them to run netstat at the client. If it doesn't show 33041 LISTENING then the other tool is wrong. 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.