In Section Service the service delivered by this protocol is described.
Section Protocol data units describes the format of the data units that are used by the
protocol entities to communicate with peer entities, and Section The underlaying service
describes the service of the underlying communication medium through
which these data units have to be communicated between peer entities.
Finally, the behaviour of one such protocol entity is described
informally in Section Protocol behaviour.
The Conference Protocol
The conference service provides a multicast service, resembling a `chatbox', to
users participating in a conference. A conference is a group of users that can
exchange messages to all conference partners in that conference. So, every user can
send messages to, or receive messages from, all its conference partners.
The partners in a conference can change dynamically because the conference service
allows its users to join and leave a conference. Different conferences
can exist at the same time, but each user can only participate in at most one
conference at a time.
The conference service has the following service primitives, with their parameters,
which can be performed at the conference service access points (CSAP):
- join(nickname, conference identifier): a user joins a named conference
and defines its nickname in this conference. The nickname identifies a user in a
- datareq(message): a user sends a message to all partners
participating in the same conference.
- dataind(nickname, message): a user receives a message from a conference
partner identified by nickname.
- leave(): a user leaves the conference. Since a user can only participate
in one conference at a time, there is no need to identify the conference in this
The service primitives join and leave are used for conference control.
The service primitives datareq and dataind are used for data transfer.
Note that the details of these CSAP primitives are not specified.
This freedom has to be filled in by the implementor (see Section Concrete interfaces for our choices).
The local behaviour (at a CSAP) of the conference service has the following
- a user is initially only allowed to perform a join to enter a conference.
- after performing a join, the user may send a message, by performing a
datareq, or receive a message, by performing a dataind.
- in order to stop participating in the conference, the user can issue a
leave at any time after a join. After that, another join primitive
can be performed, starting a new participation in a conference.
The remote behaviour (at a CSAP) of the conference service has the following
- each datareq causes datainds to be issued to all other conference
partners, i.e. all users who have performed a join to the conference the
sending user belongs to and have not performed a leave after that.
- due to the nature of the underlaying layer (see Section The underlaying service) messages
may get lost or may be delivered out of sequence but are never corrupted.
- together with each delivered message the nickname of the sending user is
transferred to the receiving user.
The conference protocol entities (CPEs) are responsible for providing the conference
service. They use the conference service primitives to build protocol data units (PDUs),
and vica versa. These PDUs are then exchanged via the underlaying layer
service (see Section The underlaying service). A conference protocol entity has the following
Protocol data units
- join-PDU: informs all potential
conference partners (see Section Protocol behaviour) that the sending user joins a
- answer-PDU: informs the receiver of this PDU that its sender is
participating in the same conference as was indicated by the
- data-PDU: informs all conference partners of the message contained in
- leave-PDU: informs all conference partners that a certain user leaves the
Figure 1 shows the encoding of PDUs in octetstrings. The nickname
and the conference identifier fields in the join-PDU, answer-PDU
and leave-PDU are ASCII characters, right aligned and with padding
zeros. For example the nickname Peter is coded (in hexadecimal) as: 00 00
00 00 00 50 65 74 65 72.
Note that the size of a data-PDU depends on the actual value of the length field.
This length field indicates the actual length of the data field in the
The underlaying service
The underlaying service is a point-to-point connectionless service provided by the
User Datagram Protocol (UDP)
]. The service primitives of the
connectionless service provided by UDP are:
- udp_datareq(destination address, data): the UDP Service user sends data,
which is a PDU, to the protocol entity indicated by
the destination address.
- udp_dataind(source address, data): the UDP Service user receives data,
which is a PDU, from the protocol entity indicated by the source address.
PDUs are packed as data elements, and sent (received) by the UDP layer using
udp_datareq and udp_dataind, respectively.
Since the udp_dataind primitive carries the source address, there is no
need to include this information in the data element.
The behaviour at the underlaying service access point (USAP) of the UDP service is
a connectionless, unreliable service and, therefore, data packages may get lost or be
delivered out of sequence but are never corrupted or misdelivered.
Each conference protocol entitiy (CPE) is responsible for the administration of
their conference partners, and for the transfer of data between conference partners.
Every CPE is initialized with a set of potential conference partners.
This set contains all users which might be a partner in a conference. This
set can be extracted from the configuration file (see Section Concrete interfaces) during the initialization phase.
Each CPE that is involved in a conference keeps track of a set of conference
partners. This set contains references to all peer CPEs (partners) that participate
in the same conference (and hence is a subset of the set of potential
conference partners). The CPE registers for each partner a mapping from the partners
address to nickname.
The normal behaviour of a CPE is defined in terms of simple (informal) rules as
- each CPE that performs a join primitive sends join-PDUs to all
potential conference partners.
- a CPE that receives a join-PDU and participates in the same conference
always sends an answer-PDU back to the sender of the join-PDU. The CPE
only includes the sender in its set of conference partners if the sender is
a member of the set of potential conference partners.
- a CPE that receives a join-PDU and does not participate in the same
conference ignores the received join-PDU.
- a CPE that receives an answer-PDU only includes the address and the
nickname of the sender in its set of conference partners if the conference
is the same and is a member of the set of potential conference
partners, otherwise the answer-PDU is ignored.
- a CPE that performs a datareq sends the corresponding data-PDU
to all conference partners.
- a CPE that receives a data-PDU delivers the message contained in this
data-PDU to its user by executing a dataind. The nickname of the
dataind is obtained by translating the source address to the nickname
according to the information contained in the set of conference partners.
- a CPE that performs a leave sends a leave-PDU to all CPEs in its
set of conference partners and clears its set of conference partners.
- a CPE that receives a leave-PDU removes the conference partner
specified by the leave-PDU from the set of conference partners.
- the loss of an answer-PDU makes it possible for a data-PDU to
arrive, which does not belong to the set of conference partners of a protocol
entity. Therefore, we compensate the loss of an answer-PDU by sending a join-PDU
to the source protocol entity of a data-PDU in case this entity does not
belong to the set of conference partners. If an answer-PDU arrives for
this join-PDU the set of conference partners can be updated accordingly.
This page was last updated by Jan Feenstra on