Sockets Closing In Rmi

Question

I'v asked the question before but I was not fully ansered.
So sorry for the cross post.
I'm a newbie in Rmi I generaly use Object streams
To write C/S programs .
I'd like to know the understand the sockets mechnism underneath Rmi .
Client Side In plain socket C/S
once I establish a socket connection I use it for all subseqent calls to the server and close it.
Client Side Rmi
serverObject = Naming.lookup(serverObjectName);//opens a socket to server.[]
serverObjcet.helloMethod();[i]// the socket is used
serverObjcet.byeMethod();// the same socket is use
1. Closing Socket :I have not seen any close method used explicitly to close to close the connection to the server .when are the clent socket is closed.
2 are sockets s are opened and closed per remote
method call .
3.a good link about the topic how the sockets are handles in rmi.
fiontan, your help is needed
Thanks!
Joseph.

Answer 1

RMI creates listening sockets, one for each listened-to port. RMI
also creates connection sockets for outgoing connections and
connection sockets for incoming connections.
The number of listening sockets is usually one, because RMI exports
all objects on the "default" port unless told to use a different port
(for example, the Registry specifically requests port 1099).
The number of outgoing connections depends solely on the number of
concurrent outgoing calls. The simple rule is: if a thread wants to
make a remote call, and all the connections to the endpoint are in
use, then RMI opens a new connection to carry the call. If a
connection is free (meaning: there's no call in progress using that
connection), then RMI will reuse it for the next remote call.
RMI spawns one thread to listen to each listening socket (again,
usually one). When RMI accepts a new connection, it creates a new
thread: one thread handles the new connection, and the other goes back
to accept a new connection. When the connection closes, its
associated thread exits.
The connection-handling threads spawned by RMI are not serialized in
any way. If the calls arrive at the same time, they'll be run in
concurrent threads. The calls are still allowed to synchronize on
Java objects (such as JDBC Connection objects), but RMI does not do
such synchronization automatically.
One thing that commonly confuses people is that if a remote stub is
returned by a remote call, the client can sometimes be seen to make
two connections to the server. That happened because the distributed
garbage-collection subsystem needed to make a DGC.dirty() call to
notify the server that a new entity held a reference to the remote
object. Since the existing connection was busy, a new one was made.
Since then, we've found a way to do it with one connection (was that
in 1.1.6? can't remember).
Someone mentioned sockets. Sockets are not the same as
connections. There are two types of socket (for the purposes of this
discussion): connection sockets and listening sockets. A connection
socket is found on each end of an open TCP connection. A listening
socket is not associated with any TCP connection, but only exists as
an abstraction to allow the TCP kernel to decide which incoming
connections get accepted, and who gets the newly-accepted connection
socket (for those of you reading RFC-793, it's a wildcard-TCB which
executes passive-opens).
At any time, RMI has a small number of listening sockets (again,
usually one), and one connection socket for each open connection
(incoming or outgoing, it doesn't matter once the connection is
open). Note that the other end of a connection also has a socket; if
both ends of the connection are on the same machine, that machine's
TCB list will include both sockets.
If you run netstat, you'll notice the listening sockets are marked (in
state LISTEN) with "*" in place of the hostname, and "*.*" for the
remote endpoint. You'll also see a line for every connection socket
(TCB) in the ESTABLISHED state, giving the TCP addresses of each end
of the connection (this end and that end, respectively). If the
connection is to the local machine, you'll see the other socket as
well, with the TCP addresses the other way around. Here's an example:
% netstat -f inet -a | grep 1099
*.1099 *.* 0 0 0 0 LISTEN
replica.43559 replica.1099 32768 0 8192 0 ESTABLISHED
replica.1099 replica.43559 8192 0 32768 0 ESTABLISHED
I took this snapshot while running Registry.list() on my machine's
rmiregistry. The first line is the listening socket inside
rmiregistry. The second line is regtool's socket for the connection
to the registry. Notice that the kernel automatically assigned the
port number 43559 to the socket. The third line is rmiregistry's
socket for the same connection. (The four columns of numbers are
details of TCP's flow-control mechanism.)
I have one report that if you run netstat on Windows NT, it will show
lots of phantom LISTEN TCBs for connection sockets (for instance, it
would have shown a "*.43559 ... LISTEN" line in the example above). I
have no idea why it does this.