Consequences of limiting RMI to one port

I would like to be able to restrict the ports used by my application to some small, possibly well-known set. The application uses Java RMI to communicate with the remote server. The registry is exported to port 1099, which is standard. However, it seems that the port used to export various remote objects is not always consistent, although it remains unchanged for several connections over a short period of time. My uneducated guess is some caching of server sockets that happen behind the scenes that causes this.

I would like to be able to make sure that the connection always occurs on several known ports, so that the users who install the client application need to open as few ports as possible in their firewall. It seems that I could do this by changing RMISocketFactory to a custom implementation and overriding the createServerSocket method to always use a known port. However, several questions arise:

  • How does this affect scalability? It sounds great if I knew that only one person would ever connect at a time, but would he block multiple simultaneous connections?
  • Can these remote objects be associated with the same port as the registry? My intuition says no, because the port will already be connected by a call to createRegistry .
  • Are there any other consequences that I don't know about?
+3
source share
1 answer

Will it block multiple simultaneous connections?

No.

Can these remote objects be associated with the same port as the registry? My intuition says no, because the port will already be bound by a call to createRegistry() .

Yes, as long as you run the registry in one JVM, through LocateRegistry.createRegistry() and as long as any equal() server socket factories are involved.

Are there any other consequences that I don't know about?

There are no consequences. RMI shares ports between remote sites with zero or equal server socket factories, and TCP shares ports between multiple connections on the same port.

+3
source

Source: https://habr.com/ru/post/1242664/


All Articles