Titan implements a peer-to-peer overlay network message routing service. By using distributed hash table (DHT) techniques, this service reliably routes messages among the applications using the service in an environment where the participating components (nodes) are heterogeneous, casually participating, potentially unavailable, and even to some degree malicious.
In addition to routing messages among the nodes comprising the Titan overlay network, Titan models a pool in which Titan objects exist and are named by unique names. While these objects are fundamentally hosted on, or in some cases bound to, nodes comprising the system, Titan abstracts away the details of which node is hosting which object and instead provides interfaces where messages are sent to and from objects solely by their names and not by their location. The maximum and minimum number of copies of an object in the system is enforced by the object pool, and objects may be singletons, or arbitrarily cached and copied as needed.
Titan objects can represent anything that can be modeled in software. From simple stored data, to applications, services, programming platforms, infrastructure devices, users and computers a Titan object models the component and is the interface between Titan messages and the effects of these messages on the objects in the pool.
Every Titan node periodically advertises the availability of the objects that it can access, and the unavailability of objects that it previously accessed but no longer. These advertisements refresh the soft-state maintained by the pool recording which object is currently located on which nodes. From this basic function, any object can be located dynamically using the message routing infrastructure of the DHT overlay network. Objects may be mobile within the Titan pool, whether they are physically moving around in an environment or are simply copies or opportunistic caches of data objects, and the advertisment operations permit the maintenance of dynamic object location information.
From the client or application programme’s perspective, a message is sent to a named object and a response returned. Some objects may be replicated on, or available from, many nodes in the system in an attempt to ensure availability and, because of the way Titan routes messages, the more replicas of an object that exist in the object pool a message will probabilistically traverse a small number of DHT traversals to reach the destination object. Thus the more object replicas there are, the more the load is distributed and the better the system performs.
Titan objects are free to implement their own behaviour corresponding to the messages they receive as well as specifying to the pool how to manage the object’s life-cycle, such as the degree of replication in the pool, the time-to-live of an object replica, active re-duplication to maintain availability, active de-duplication to prevent filling the pool with an excessive number of copies, opportunistic caching, and even controlled deletion. Each message received by an object induces some operation by the object and necessarily produces a response message which is returned to the sender of the original message. Example operations are to return some stored data, send messages to other objects, or interface to some external component such as a sensor, actuator, or independent application. In practice, the vast majority of objects are immutable and represent a service (and the majority of these have been services that simply encapsulate some stored data), and any single object found in the set of replicas is sufficient to respond to a message. For objects that are not immutable, that is to say messages can modify the persistent state of the object, Titan provides a Mutable Object service for implementing strict consistency mutable objects in the pool while maintaining availability in the environment where participating components (nodes) are heterogeneous, casually participating, potentially unavailable, and even to some degree malicious.