Question

If you want to use custom sockets for RMI (e.g. using SSL), in UnicastRemoteObject.exportObject(4) you need to specify a client socket factory as well as a server socket factory. But the exporting of objects is done on the server side. Why is the client socket factory necessary?

Unless…it’s serialized and used by client wanting to acquire a connection to that object? I find that unlikely (though it may be the answer); (SSL) Socket factories don’t sound like classic examples of serializable objects to me, with keystores being local, and things like that.

Answer 1

Yes, just like you said already in the question:

An RMIClientSocketFactory must be serializable, and will be serialized to the client other side, when used with exportObject or UnicastRemoteObject’s constructor.

This means that it must not contain (non-transient) references to objects which are non-serializable, only the necessary information to create a socket on the fly.

(I recently posted an example for a RMISocketFactory, where I needed to take care to be serializable.)

---

Edit (after the comment from EJP):

Of course, this only applies if you need to use a client socket factory at all. In many circumstances, you simply can use the other exportObject methods (or other constructors), which then use the default server socket factory on the server side, and the default client socket factory at the client side, without serializing anything.

And yes, there is no point of serializing the server’s trust store to the client – if the client has to trust the registry or other remote objects for which certificates to accept, we have the point for a man-in-the-middle attack. Thus SslRMIClientSocketFactory, while being Serializable, does not serialize the server’s SSL context, but simply uses the client VM’s SSL settings.