I'd like to be able to restrict the ports used by my application to some small-as-possible known set. The application uses Java RMI to communicate with a remote server. The registry is exported on port 1099, which is standard. However, it appears that the port used to export the various remote objects is not always consistent, though it does stay the same across multiple connections over a short period of time. My uneducated guess is there is some sort of caching of the server sockets going on behind the scenes which causes this.
I'd like to be able to ensure that the connection always occurs over a few well-known ports, so that users who install the client application have to open as few ports as possible in their firewall. It seems that I could do this by changing the RMISocketFactory to a custom implementation and override the createServerSocket method to always use a known port. However, this raises a few questions:
- How does this affect scalability? It sounds great if I knew only one person would ever connect at a time, but wouldn't it block multiple simultaneous connections?
- Is it possible to bind these remote objects on the same port as the registry? My intuition says no, as the port would already be bound by the
createRegistrycall. - Are there other implications I am ignorant of?
wouldn't it block multiple simultaneous connections?
No.
Is it possible to bind these remote objects on the same port as the registry? My intuition says no, as the port would already be bound by the
createRegistry()call.
Yes, as long as you start the registry in the same JVM, via LocateRegistry.createRegistry(), and as long as any server socket factories involved are equal().
Are there other implications I am ignorant of?
There are no implications at all. RMI does port sharing between remote objects with null or equal server socket factories, and TCP does port sharing between multiple connections to the same port.
来源：https://stackoverflow.com/questions/9366240/implications-of-restricting-rmi-to-one-port