This content has been marked as final. Show 12 replies
i have a requirement to fix the server and client ports being used by our RMI app.Fixing the client ports is a figment of netadmin's imagination. It is unprogrammable except with great difficulty; it has major drawbacks to the client application, such as adding both latency and unreliability; and it adds nothing to network security whatsoever.
Fixing the server ports on the other hand is entirely trivial. Just quote the port number required when exporting your remote objects, typically via super(port) if they extend UnicastRemoteObject; if they don't, UnicastRemoteObject.exportObject() can take a port parameter.
No need for custom socket factories whatsoever. And specifically no need whatsoever for using a custom RMISocketFactory. That API is 13 years out of date. Have a look at RMIClientSocketFactory, and RMIServerSocketFactory if necessary. It is not necessary in this case.
However , apart from the ports defined in the CustomRMISocketFactory there are other ports that i still see in the network traces.DGC ports.
From the debug that i have done i see that these ports are being generated right after the Naming.lookup(<String>) call.DGC ports between the Regsitry and the client.
Please do let me know if anyone can guide me in the correct path.See above.
Thanks a ton for the insight !
Yeah i was using the RMIClientSocketFactory and the RMIServerSocketFactory in my code. i used that term(RMISocketFactory) to imply that. Sorry if that caused trouble :(
i have the following queries,
i. Is there any published document that iterates the fact that fixing the client ports is not recommended alongside the reasons. i do understand the reasons but a document reference would help immensely. Maybe a pointer to where i can look for such documentation.
ii. If i understand correctly the ports used by DGC to keep track of client references should/cannot be fixed. This would imply that with a firewall sitting between the client and server the DGC operation would be interrupted. That is even if the ports used by the server side are fixed its only upto a certain level and some randomly selected ports would continue to be used for the DGC operation to run smooth.
Please correct me if any of the statements do not make sense.
Much appreciate your help !
Thanks a ton !
i. Is there any published document that iterates the fact that fixing the client ports is not recommended alongside the reasons. i do understand the reasons but a document reference would help immensely. Maybe a pointer to where i can look for such documentation.Search these forums, both the Networking forum and the read-only Socket Programming forum if you can find it. I have expressed my views about this on a large number of occasions, and nobody has ever refuted them or even questioned them, in 14 years.
The fact is that the Sockets API simply does not provide a way to specify a range of outbound ports when creating a connection, and neither does Java, either at the Socket level or at the RMI level. Some firewalls provide the ability to create rules for outbound port ranges, but that is only by symmetry with incoming port ranges, i.e. using the same configuration code for both.
So, as there is no application support for outbound port ranges, they should not be specified. Period.
However I would take the other tack: let those who are in favour of outbound port ranges (a) provide concrete reasons as to how doing so improves network security, and (b) indicate how to implement it. In Java RMI.
ii. If i understand correctly the ports used by DGC to keep track of client references should/cannot be fixed.In the absence of socket factories, there is automatic port sharing, i.e. once you have exported an object on a port, any port, whether user-defined or chosen by the system, all subsequent objects are exported on the same port unless you specify otherwise. That should apply to the DGC object as well as your own. I would guess that your socket factories got in the way of that, and once you remove them it will all fix itself nicely.
Sorry for that ! I didnt mean to refute or challenge your views in any way. Its just that some people are convinced on seeing some documentation. For them logic does not work. i will convince them :)
You are a great help !
Yes i followed what you advised and now thanks to you not only i have been able to achieve a major part of what i was trying to but also managed to learn a great deal about the internal workings of RMI and sockets ...
Thanks a ton again !
i will start a new thread if i have any other related queries !
BTW just a curious question ...
Where does the port numbers used by the client code come from.
Can you point me to some place/documents where i can just read through where the client ports come from ? ie. from the underlying socket layer that is beyond programmatic control or by some other method.
i implemented the subclasses of UnicastRemoteObject to provide a port range on the server side.
However when i incorporate changes in the RMIClientSocketFactory the changes on the client ports do not reflect.
Is it possible that passing the port number in the super() call of the subclasses of UniCastRemoteObject somehow affects the socketfactory ?
Much thanks !
Let me clarify ,
i am not using the socket factory to set the fixed ports on the server.
For the ports on the server i used the super(port) call in the subclasses of UnicastRemoteObject.
And that did fix the server ports.
However being curious i wanted to see how can i fix the ports on the client.
So i used a customized RMIClientSocketFactory.(w.r.t your note in this thread).
And overrid the createSocket method to fix the ports on the client.
But i do not see the ports mentioned in the method being used.
i need to understand where i went wrong(while attempting to fix ports on the client).
Maybe i misunderstood your post related to the ways to attempt to fix the client port numbers.
Much thanks ,
Edited by: 843336 on Mar 15, 2011 1:00 PM