2 Identifiers
Ensemble uses a variety of identifiers for a variety of different
purposes. Here we summarize the important ones and describe what they
are used for. Their type definitions can be found in the
type directory in the file corresponding to the name.
Look in type/README for an up to date listing of these files.
Most of the different identifiers support a similar interface for a
variety of operations. Several of the identifiers are opaque, in the
sense that the interface hides the actual structure of the identifier.
All identifiers have a string_of_id function defined which
gives a human-readable description of their contents.
Changes from Horus
-
None of the identifiers are defined as fixed length sequences of
bytes. This is something that remains to be done.
-
Horus EID's have been split into endpoint and group identifiers.
-
We have removed addressing information entirely from endpoint and
group identifiers.
-
Entity identifiers have been eliminated. Connection, stack, and
protocol identifiers have been added to support a variety of features
new to Ensemble.
2.1 Endpoint Identifiers
Endpoint identifiers are unique names for communication endpoints. A
single process can create any number of local endpoint identifiers,
each of which is guaranteed to be unique (within some limits). A
process can have multiple endpoints in a single group. An endpoint
can be a member of multiple groups. However, the endpoints in a group
must be distinct.
2.2 Group Identifiers
Group identifiers serve as unique names of communication groups. They
do not contain addressing information. The exception to this rule is
that groups communicating via Deering multicast choose a random
multicast address by taking a hash of the group address. Processes
can create any number of local group identifiers, each of which is
guaranteed to be unique (within some limits).
2.3 View Identifiers
View identifiers are unique identifiers of group views. Whenever
communication protocols proceed through a view change, the resulting
view is given a new view identifier. These are made unique by pairing
the coordinator of the group with a logical timestamp that is advanced
whenever a view change happens. Although two partitions of a group
may share the same time stamp, they will have different coordinators.
2.4 Connection Identifiers
Connection identifiers are used to route messages to the precise
destinations. They specify the exact destination endpoint or group,
the view identifier, the protocol stack to deliver to, the type of
protocol being used to send the message, as well as several other bits
of information. Typically, endpoint or group identifiers are used to
send messages to the correct processes and connection identifiers are
used to route messages to the exact destination of a message within a
process. Messages usually contain a connection identifier as a
``header'' of the message but do not contain endpoint identifiers or
group identifiers, except as subfields of a connection identifier.
2.5 Protocol Identifiers
There is a one-to-one relationship between the standard protocol
stacks of Ensemble and protocol identifiers. Applications select
the protocol to use by specifying the protocol id of that stack.
Having identifiers for protocols is convenient because they can be
passed around in messages and have equality comparisons made on them,
whereas the actual protocol stacks cannot.
2.6 Mode identifiers
Each communication domain has a corresponding mode identifier used to
specify that domain.
2.7 Stack Identifiers
Stack identifiers are used to distinguish between the various domains that
a protocol stack may be receiving messages through. Each of the various
kinds of ``channels'' that protocol stacks use has a separate identifier.
Currently, these are:
-
Primary :
- This is the primary communication channel for a protocol stack.
This is normally where most messages are received.
- Bypass :
- Messages sent via the optimized bypass protocols use this id.
- Gossip :
- Messages sent by group merge protocols use this id.
- Unreliable :
- This stack id is reserved for unreliable stacks.