about socket reuse in RMI
peter.jones at sun.com
Tue Jun 26 05:49:10 UTC 2007
On Sat, Jun 23, 2007 at 08:42:19PM +0800, zhang Jackie wrote:
> socket reuse in RMI confused me much for several reasons:
> In my opionion, one socket is boud some information about server and
> port(right?), how such socket can be reused to communicate to
> another server,just change the IP address and port number? Is it
> possible to do so in user space of linux?
There is nothing like that going on. There is connection reuse: when
an invocation is made on a remote stub with a given "endpoint"-- the
triple of host, port, and RMIClientSocketFactory values-- then if
there is currently an idle JRMP connection open to that endpoint, it
will be reused for communicating the invocation (pending security
checks) instead of opening a new connection. That's likely what is
meant by a reference to "socket reuse in RMI"-- sockets themselves are
not reused for more than one connection.
> ServerSocket is used to accept new connection, one ServerSocket
> instance can fit the need of application, why reuse is needed. What
> the socket reuse of RMI means?
And server sockets are not reused for more than one "listen", if
that's what you're asking. Server socket "reuse" in the context of
RMI likely refers to the fact that when multiple remote objects are
exported with the same port and RMIServerSocketFactory values,
invocations on all of them will be accepted over the same server
> Some one give me such a comment:
> *RMI will reuse sockets if the socket was created by the same socket
> factory. So, if two remote object's socket factories that are
> .equal() then RMI will reuse a client's socket to talk with each RMI
> object. It will also reuse that socket for multiple calls to those
> remote objects. *
> So this is not socket factory reuse ,rather than socket reuse.
I think that the quoted person was referring to connection reuse.
> I was confused greatly, Do everyone can give me a clear explanation
> about this topic?
Does the above help?
More information about the core-libs-dev