RMI port on client side

[yellowtek]

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.

 

[EJP]

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.

 

[yellowtek]

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 :

 

[EJP]

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.

 

[yellowtek]

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
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 :

 

[Nigel Wade]

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...]

 

[EJP]

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.

 

[yellowtek]

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.

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.

 

[EJP]

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.