RMI Summary

UnicastRemoteObject.exportObject expose a remote object at given ip and port

LocateRegistry.getRegistry.bind register a remote object to registry, note that registrty is also a remote object, and the registry service need to be started in advanced.
set CLASSPATH=D:\workspace\BuGu\bugu_core_test\bin
start rmiregistry
LocateRegistry.createRegistry(1099);

can i specify ip and port instead of using registry?

can it be bi-directional?
client expose a object implemented Remote interface or use a object extends UnicastRemoteObject.

can bi-direction works when client is behide a gateway or firewall?

RemoteObject contains reference to RemoteRef, and provide re-implementation for Object's method.
RemoteRef handles calling methods on a remote object, subclasses of RemoteStub and RemoteObjectInvocationHandler (Used to create proxy) deletgates method call to this object.
Stub and proxy can be published on server and then be serialized to client?

Class that do not extends UnicastRemoteObject will not has it's equals/hashcode... methods implemented correctly

Besides RemoteStub and RemoteObjectInvocationHandler, why RemoteServer need to extends RemoteObject?
Know that UnicastRemoteObject don't need a RemoteRef in constructor, this means that it creates a implementation of RemoteRef by itself.

Stub will contain RMIClientSocketFactory, which will be serialized to client and be used to create socket connection.

When passing an exported remote object as a parameter or return value in a remote method call, the stub for that remote object is passed instead. Remote objects that are not exported will not be replaced with a stub instance.

Within a single remote method call, the RMI system maintains referential integrity among the objects passed as parameters or as a return value in the call.

When an object is sent from one JVM to another in a remote method call, the RMI system annotates the class descriptor in the call stream with information (the URL) of the class so that the class can be loaded at the receiver. It is a requirement that classes be downloaded on demand during remote method invocation.
RMI’s subclass of ObjectOutputStream also implements the annotateClass method that annotates the call stream with the location of the class so that it can be downloaded at the receiver.
This is why only java5 don't need to create stub manually?

The ObjectOutputStream subclass overrides the replaceObject method to replace each exported remote object with its corresponding stub instance.
A stub for a remote object is obtained via a call to the method java.rmi.server.RemoteObject.toStub.

Registry use Naming?

Why need to register a stub not the orginal object?

skeletons are not used since 1.2, ignore it.

A remote object implementation needs to make sure its implementation is thread-safe.

RMI uses a referencecounting garbage collection algorithm, the counter increase when stub is created and descrease when stub is claimed. When remote object's counter is zero, RMI changed to use a weak reference to hold it, therefore, if there's no local reference to it, it can be claimed by JVM at anytime!
Implement java.rmi.server.Unreferenced to get notified when no client refers to it.

The RMIClassLoader provide methods to get the codebase and load class from codebase.

RMISocketFactory
First, a direct socket connection to the remote VM is attempted. If that fails (due to a firewall), the runtime uses HTTP with the explicit port number of the server. If the firewall does not allow this type of communication, then HTTP to a cgi-bin script on the server is used to POST the RMI call.