In a TIPC network, a Node is comprised of a collection of lightweight
threads of execution operating in the same process, or heavyweight
processes operating on the same machine. A Cluster is a collection of
Nodes operating on different machines, and operating indirectly by way
of a local Ethernet or other networking medium. Clusters may be further
aggregated into Zones, and Zones into Networks. The address space of two
TIPC networks is completely disjoint. Zones on different networks may
coexist on the same LAN but they may not communicate directly with one
another.
TIPC provides connectionless, connection-oriented, reliable, and
unreliable forwarding strategies for both stream and message oriented
applications. But not all strategies can be used in every application.
For example, there is no such thing as a multicast byte stream. The
strategy is selected by the user for the application when the socket is
instantiated.
TIPC is not TCP/IP based. Consequently, it cannot signal beyond a
local network span without some kind of tunneling mechanism. TIPC is
designed to facilitate deployment of distributed applications, where
certain aspects of the application may be segregated, and then delegated
and/or duplicated over several machines on the same LAN. The application
is unaware of the topology of the network on which it is running. It
could be a few threads operating in the same process, several processes
operating on the same machine, or it could be dozens or even hundreds of
machines operating on the same LAN, all operating as a unit. TIPC
manages all of this complexity so that the programmer doesn't have to.
Unlike TCP/IP, TIPC does not assign network addresses to network
interfaces; it assigns addresses (e.g. port-ids) to sockets when they
are instantiated. The address is unique and persists only as long as the
socket persists. A single Node therefore, may typically have many TIPC
addresses active at any one time, each assigned to an active socket.
TIPC also provides a means that a process can use to bind a socket to a
well-known address (e.g. a service). Several peers may bind to the same
well-known address, thereby enabling multi-server topologies. And server
members may exist anywhere in the Zone. TIPC manages the distribution of
client requests among the membership of the server group. A server
instance responds to two addresses: its public well-known address that
it is bound to, and that a client may use to establish a communication
with a service, and its private address that the server instance may use
to directly interact with a client instance.
TIPC also enables multicast and "publish and subscribe" regimes that
applications may use to facilitate asynchronous exchange of datagrams
with a number of anonymous sources that may come and go over time. One
such regime is implemented as a naming service managed by a distributed
topology server. The topology server provides surveillance on the
comings and goings of publishers, with advice to interested subscribers
in the form of event notifications, emitted when a publisher's status
changes. For example, when a server application binds to a TIPC address
, that address is automatically associated with that server instance in
topology server's name table. This has the side effect of causing a
"published" event to be emitted to all interested subscribers.
Conversely, when the server's socket is closed or when one of its
addresses is released using the "no-scope" option of tipc_bind/3,
a "withdrawn" event is emitted. See tipc_service_port_monitor/2.
A client application may connect to the topology server in order to
interrogate the name table to determine whether or not a service is
present before actually committing to access it. See
tipc_service_exists/2
and tipc_service_probe/2.
Another way that the topology server can be applied is exemplified in
Erlang's "worker/supervisor" behavioral pattern. A supervisor thread has
no other purpose than to monitor a collection of worker threads in order
to ensure that a service is available and able to serve a common goal.
When a worker under the supervisor's care dies, the supervisor receives
the worker's "withdrawn" event, and takes some action to instantiate a
replacement. The predicate, tipc_service_port_monitor/2,
is provided specifically for this purpose. Using the service is
optional. It has applications in distributed, high-availability,
fault-tolerant, and non-stop systems.
Adding capacity to a cluster becomes an administrative function
whereby new server hardware is added to a TIPC network, then the desired
application is launched on the new server. The application binds to its
well-known address, thereby joining in the Cluster. TIPC will
automatically begin sending work to it. An administrator has tools for
gracefully removing a server from a Cluster, without effecting the
traffic moving on the Cluster.
An administrator may configure a Node to have two or more network
interfaces. Provided that each interface is invisible to the other, TIPC
will manage them as a redundant group, thus enabling high-reliability
network features such as automatic link fail-over and hot-swap.
