question for mark

[Prakash Krishnamurthy]

Mark,
I had a question regarding one of your posts. You had said in one of my questions about the parameters to be passed in the GUI, that you did not have a port number as a parameter. So then did you always run it on the default port? was there a option for the examiner to choose a port of his/her choice?
PK

[Miguel Roque]

Hi.
It's not Mark, but I can answer how I've made it. I simply start the client with java -jar FBNClient.jar and the first screen that shows up with two tabs, one for local mode where it ask's for the location of the db.db file and other tab for network mode that asks for the URL of the server and the port number.
It's a simple soluction that has been used by many of us here.
Miguel

[Max Habibi]

That's my suggestion as well.
M

[Prakash Krishnamurthy]

Thanks Miguel and Max,
I surely did not mean that the questions were not meant for the rest. Thanks again. The way you have mentioned above is pretty much the way I have done it at present.
But I was wondering if somebody had passed the exam without even the port number as a parameter. If it were so then I was thinking I could do so too; to have it run on the default port always; if somebody has passed the exam this way..then why not? just felt mark mentioned something like that in one of his previuos answers to my questions, hence the question was directed to a specific person.....

[Mark Spritzler]

Actually I took the default.
Mark

[Marcos Motta]

Can you please tell me what port you are talking about? The port the registry is bound to or the one used to export the remote object (UnicastRemoteObject.export) ?

[Prakash Krishnamurthy]

the port that you bind to

[Marcos Motta]

I am sorry to insist in this matter, but I think that my RMI knowledge is flawed. My problem is related to the use of port numbers at the client side. More specifically the port used as parameter in the client. I cant see what this parameter is good for.
I know that I can choose the registry's host and port by using Naming.lookup("//host:<port>/name"). But I dont know how to tell to the lookup process which port it must use to connect to the remote object. Actually, I think it does not make sense.
When the client talks to the registry asking for the remote object, the registry responds instructing the client to connect to the port where the object was exported to (UnicastRemoteObject.export()). Thus, the connection between the client and the remote object will allways use the port (server side) defined by the server object, not by the client.
Your opinion, please...

[Andrew Monkhouse]

Hi Marcos,
Throughout these discussions, everyone is always talking about the port the RMI Registry is listening on.
As programmers using RMI, we never know (or care) what port the server we write will be listening on, nor do we know (or care) which port the client will use to connect to the server.
During the bind process, a port numbr gets assigned to our server. I do not know whether the server gets this port number, or whether it is assigned by the registry. I think the second option is more logical, but I just dont know (and dont really care ). This number is dynamic (that is, it can (and probably will) change each time you run your server).
So if I run my server (which starts my RMI Registry) I can see that I am now using two ports:

##### Start the server #####
[andrewm@andrewm a]$ java -jar server.jar &
[1] 8205
Lease time 30000
Attempting to start registry on port 1099
Server ready to process requests

##### Look for ports that have been bound to by a Java process #####
[andrewm@andrewm a]$ netstat -aeep --numeric-hosts  | grep LISTEN | grep java
tcp        0      0 0.0.0.0:1099            0.0.0.0:*               LISTEN      andrewm    51745      8205/java           
tcp        0      0 0.0.0.0:33528           0.0.0.0:*               LISTEN      andrewm    51747      8205/java           

##### Confirm that these are my processes #####
[andrewm@andrewm a]$ ps -elf | grep 8205
000 S andrewm   8205  7882  2  78   0    - 52273 restor 11:15 pts/0    00:00:00 java -jar server.jar
040 S andrewm   8206  8205  0  75   0    - 52273 kill_s 11:15 pts/0    00:00:00 java -jar server.jar

I can see here that port 1099 is bound (this is the RMI Registry) and port 33528 is bound (this is the dynamically allocated port number my server is listening on).
If I kill off the server process, and then restart it, I will get a different port number:

##### Start the server #####
[andrewm@andrewm a]$ java -jar server.jar &
[1] 8236
Lease time 30000
Attempting to start registry on port 1099
Server ready to process requests
##### Look for ports that have been bound to by a Java process #####
[andrewm@andrewm a]$ netstat -aeep --numeric-hosts  | grep LISTEN | grep java
tcp        0      0 0.0.0.0:1099            0.0.0.0:*               LISTEN      andrewm    55590      8236/java           
tcp        0      0 0.0.0.0:33535           0.0.0.0:*               LISTEN      andrewm    55591      8236/java           

This time I got port number 33535 for my server.
The point is, that neither the code I write for my server, nor the code I write for my client ever needs to know this dynamic port number.
What happens is that when the server starts up, it gets allocated this changeable port number. The registry knows that the server is using that particular port number, so that is all that matters.
When the client does a lookup for the services my server is offering, the RMI Registry will tell it that the services are being offered by a server which is on "machine x, listening on port y".
As long as the client knows how to get in touch with the RMI Registry, it can always find out what port the server is listening on.
And this answers your question My problem is related to the use of port numbers at the client side. More specifically the port used as parameter in the client. I cant see what this parameter is good for.
The client uses the port number in it's lookup command to connect to the RMI Registry. The RMI Registry does not have to be on port 1099, it could be on any port. So the client specifies what port it expects to find the RMI Registry on.
Once it has connected to the RMI Registry, it can find out what port the server is on.
The server never needs to know this.
The client does not care what outgoing port number it is using to connect to the server. This is handled automatically.
The server does not care what port number the client used to connect. All the server cares about is that it has a connection.
Is this making sense?
Regards, Andrew
[ May 16, 2003: Message edited by: Andrew Monkhouse ]

[Marcos Motta]

Andrew,
I agree 99.9% with you. My only comment is:

"As programmers using RMI, we never know (or care) what port the server we write will be listening on, ..."
"During the bind process, a port numbr gets assigned to our server. I do not know whether the server gets this port number, or whether it is assigned by the registry. I think the second option is more logical, but I just dont know (and dont really care ). This number is dynamic (that is, it can (and probably will) change each time you run your server).

Actually, there is a way to determine in advance which port the svr will be listening on. It is done by using the constructor of UnicastRemoteObject that takes the form UnicastRemoteObject(port), which ultimately calls the method export(obj,port). The default ctor calls export(obj) that does not take the port number and selects an anonymous port.
A good reason for manually choosing a port number might be to make the server compatible with some security policy when the it and its clients are separated by a firewall.
Thanks for letting me know that the client ports mentioned in this forum are, mostly, meant to be for the rmiregistry.
[ May 19, 2003: Message edited by: Marcos Motta ]

[Andrew Monkhouse]

Hi Marcos,
Thanks for giving me an example of where you would want to know the port (and of how to get it).
Filing that away for future referene.
Regards, Andrew