4

Is there a method to know the port number of both the client and server during RMI?

When a result is returned during RMI to the client, next time the client requests the result, will the conversation between client and server be at the same port as the previous, when the server has been running since the first result was returned or a new port is created?

for example :

// call to a remote method add
     addServerIntf.add(d1,d2)
// after this call i get the added result

// again call the add method by again starting the client
    addServerIntf.add(d1,d2)
// I get the result back as usual

In the 2 different calls does the port number of client and server remain the same ?

My client program exits after entering a command like java AddClient localhost 100 200 The method on the server returns 300 and the client exits. Next time i start my client again with java AddClient localhost 19 100. Now will request be sent from the same port as sent from before and will the server receive the request on the same port ? Or the situation is different from what i just wrote ?

user207421
  • 305,947
  • 44
  • 307
  • 483
Suhail Gupta
  • 22,386
  • 64
  • 200
  • 328
  • 3
    I think your question is not very clear. If you bind a remote object to a certain port, it will be available there and not move to a different port. Could you show some code that indicates your problem or clarify your question? – mort Dec 21 '11 at 15:23
  • 1
    The server port of course will not change. OP is talking about the client's port. So the question is if multiple RMI calls establish a new connection to the server (resulting in a different client port) or not. – f1sh Dec 21 '11 at 15:26
  • I think you misunderstand how sockets work in general. Once an endpoint is established, the port becomes irrelevant. – Chris Dennett Dec 21 '11 at 15:33
  • @ Chris Dennett let me tell you that my client program exits after entering a command like `java AddClient localhost 100 200` The method on the server returns `300` and the client exits. Next time i start my client again with `java AddClient localhost 19 100`. Now will request be sent from the same port as sent from before and will the server receive the request on the same port ? Or the situation is different from what i just wrote ? – Suhail Gupta Dec 21 '11 at 15:45
  • 1
    Since the program exits, I would suspect that the rmi client socket is closed as well. The second call to your program would then create a new client socket which is not guaranteed to use the same port again as this is controlled by the OS. Yet I have no idea how the get a hold of the client socket instances to simply output the ports. – f1sh Dec 21 '11 at 15:51

3 Answers3

3

Is there a method to know the port number of both the client and server during RMI?

If I didn't misunderstand, I think there's no way to know the port number during a RMI session.

If you have a different port number, from the default RMI registry Server 1099 port, you have to set it, on the Server class and on the Client class, because, as the Oracle RMI page reports:

If the registry will be running on a port other than 1099, you'll need to specify the port number in the calls to LocateRegistry.getRegistry in the Server and Client classes. For example, if the registry is running on port 2001 in this example, the call to getRegistry in the server would be: 

Registry registry = LocateRegistry.getRegistry(2001);

and:

This client first obtains the stub for the registry by invoking the static LocateRegistry.getRegistry method with the hostname specified on the command line. If no hostname is specified, then null is used as the hostname indicating that the local host address should be used.

Then, my conclusion is that you can't know, with a method, the port number of a RMI session (you can check the RMI API for details), except when you have to set it, if it is different from the default RMI registry Server 1099 port, because you have to know it at the beginning of the RMI session.

Just think: How you can get this port number? Contacting the server or the client? For example, if you request a page located in a specific Server, that is listening to port 81 (not on the default 80 port), you need in advance the port number to connect to this specific Server, contacting it, for example on: http://192.168.1.1:81. Then, during a RMI session you must know in advance the RMI registry port.

Check this page for details.

When a result is returned during RMI to the client, next time the client requests the result, will the conversation between client and server be at the same port as the previous, when the server has been running since the first result was returned or a new port is created?

When the result is returned to the client, the conversation between Client and Server should be shared on the same RMI registry port, otherwise, if the RMI registry port set in the client is different from the Server RMI registry port (if I didn't forgot), the code will throw a RemoteException, that can occur when a failure occurs in the RMI process.

UPDATE

Now I see your updated question.

In the 2 different calls does the port number of client and server remain the same ?

It should be the same RMI registry Server port. When your program exits after the first call, the program closes the socket connection. The next time you start the program, the RMI registry port should be the same. Otherwise, your program should throw an exception, or, when you pass your arguments to the program, you get an unexpected result. If I understood, your client program simply calls a sum method on the Server. After the first result, the next time you start the program, do you get a different result? If not, I think the RMI registry port is the same.

Alberto Solano
  • 7,972
  • 3
  • 38
  • 61
  • *Moderator note:* comments under this answer were nothing more than an argument over whose answer is correct, and have been purged. Please keep comments constructive and on topic, and please also cast votes wisely. – BoltClock Dec 24 '11 at 17:02
  • "the conversation between Client and Server should be shared on the same RMI registry port" isn't correct. It *may* be shared on the Registry port under certain conditions. – user207421 Dec 26 '14 at 09:04
2

Is there a method to know the port number of both the client and server?

No. You can't know the client port number in advance, as it is allocated dynamically on connection, and the server IP:port is embedded in the stub where you can't get at it. Why would you need to know? The information can't do you much good: you can't use it.

When a result is returned during RMI to the client, next time the client requests the result, will the conversation between client and server be at the same port as the previous, when the server has been running since the first result was returned or a new port is created?

Either:

  • The client connection is reused, with the same port number, or
  • A new connection with probably a new local port is created at the client.

It is impossible to tell which. The server port remains fixed.

In the 2 different calls does the port number of client and server remain the same ?

See above.

My client program exits after entering a command like java AddClient localhost 100 200. The method on the server returns 300 and the client exits. Next time i start my client again with java AddClient localhost 19 100. Now will request be sent from the same port as sent from before

Probably not.

and will the server receive the request on the same port?

Impossible to say without seeing your server code. If you exported it on a constant port, it is exported on a constant port. If not, not. Tautology really.

Or the situation is different from what i just wrote?

I don't understand the question.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • 2
    @downvoter Please explain. Unexplained downvotes don't do anybody any good: not the poster, the OP, or the community. If you think there is an error in the above please specify. – user207421 Dec 24 '11 at 08:42
  • Do you care to explain *the server IP:port is embedded in the stub where you can't get at it...* ! I think `LocateRegistry.getRegstry(int port_number);` would already allow client to know about the server port_number and/or IP.. – Am_I_Helpful Aug 24 '15 at 12:11
  • 1
    @Am_I_Helpful The stub returned by `LocateRegistry.getRegistry()` is a *Registry* stub; it's still a stub, which is opaque to the application; and it contains the port number you provided to it as a parameter, which you already knew. It isn't a solution to this question. NB A downvote for not responding to a comment isn't how SO is supposed to work IMO. – user207421 Aug 25 '15 at 04:52
  • @EJB "IP:port is embedded in the stub where you can't get at it." -- if the client prints the remote object recieved after lookup, the server side ip and port would be shown in log.At times helpful during analysis of network packet capture between the application. – Nrj Oct 09 '17 at 12:24
  • @Nrj The OP asked for a *method,* and there isn't one. – user207421 Jan 30 '19 at 23:54
-1

Know your TCP/IP: A client connects to a server on a certain port. The client port number is random (or it should be for security reasons), the server port number is known (otherwise, there would be no way for the client to connect in the first place).

The TCP/IP protocol will then establish a connection. The server will create a handler for the connection and TCP/IP will assign this connection a new, random port. The port number on the server side doesn't change. Since the server can use the client's IP+port as a key to distinguish different "sessions", any number of clients can connect to the same server port.

This means: After the RMI framework is initialized, both client and server will talk to each other over a pair of ports that doesn't change as long as the connection exists.

If the connection is severed for some reason, a new connection can be established but that will probably get a new port numbers on both sides the client side.

my client program exits

This means the connection is severed. When you start the client again, a new client port is created. It most likely (at a chance of 65534:65535 which is roughly 1) will be a new port number.

If you start the client again within two minutes, the port numbers must be different because the old ports are is kept alive for two minutes to make sure the "remote TCP received the acknowledgment of its connection termination request" (if you run netstat, you will see these with the status TIME_WAIT).

user207421
  • 305,947
  • 44
  • 307
  • 483
Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • Completely incorrect. accept() creates a new socket with the listening socket's IP:port as the local address and the client's IP:port as the target address. – user207421 Dec 23 '11 at 02:47
  • EJP: Completely incorrect. How do you think new clients can connect when the new socket blocks the listening port? And even if I got this detail wrong, the rest of the answer would be still correct. – Aaron Digulla Dec 23 '11 at 11:35
  • Please read the TCP RFC or check the output of 'netstat' before you reiterate this error, and don't downvote correct answers on topics on which you are misinformed. Your entire answer consists of variations on this mistake: there is no 'rest' of it that 'would still be correct'. – user207421 Dec 23 '11 at 22:05
  • Improved my answer with information from Wikipedia and the RFCs. I think I mixed that up with FTP which does open new ports for data connections. PS: Saying "Completely incorrect" is not a good way to try to correct me. It pissed me off. – Aaron Digulla Dec 27 '11 at 08:26
  • 1
    I don't see what FTP, an application protocol, has to do with either RMI, another application protocol, or TCP, a session protocol. PS: Having correct comments contradicted, and correct answers downvoted, is also mildly irritating ;-) – user207421 Dec 28 '11 at 10:19