Comparison to DRb

Ruby already has a distributed object system as part of its standard library: DRb, which stands for Distributed Ruby. What's wrong with DRb? Why do we need a new system? DRb has one major drawback: it's inherently synchronous. The only thing you can do to an object is to make a method call, which sends a remote object a message, executes the method, and returns a response.

Under the covers, DCell uses an asynchronous message protocol. Asynchronous messaging allows many more modes of messaging than the standard request/response pattern afforded by DRb, including:

• Broadcast: Send a message to many actors without waiting for a response
• Publish/Subscribe: Actors register interest in a topic, and other actors publish to all interested subscribers
• Scatter/Gather: Send messages to many actors in parallel, and obtain responses as data is available
• Multicall/Quorum: Make a call to many actors, and wait for a quorum to respond

DCell also provides an Erlang-inspired approach to fault-tolerance, advocating that actors shouldn't handle errors but should crash and restart in a clean state. Linking to actors on remote nodes can be used to detect these sorts of errors and have dependent actors restart in a clean state.

Finally, where DRb makes you write thread-safe objects to expose as services, Celluloid abstracts the thread safety concerns away, making sure your objects are thread-safe by default.