The Conference Protocol

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.

Service

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 conference.
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 primitive.

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 characteristics:

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 characteristics:

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.

Protocol data units

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 PDUs:

join-PDU: informs all potential conference partners (see Section Protocol behaviour) that the sending user joins a certain conference.
answer-PDU: informs the receiver of this PDU that its sender is participating in the same conference as was indicated by the join-PDU.
data-PDU: informs all conference partners of the message contained in this data-PDU.
leave-PDU: informs all conference partners that a certain user leaves the conference.

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 data-PDU.

The underlaying service

The underlaying service is a point-to-point connectionless service provided by the User Datagram Protocol (UDP) [Com91]. 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.

Protocol behaviour

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 follows:

1.: each CPE that performs a join primitive sends join-PDUs to all potential conference partners.
2.: 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.
3.: a CPE that receives a join-PDU and does not participate in the same conference ignores the received join-PDU.
4.: 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.
5.: a CPE that performs a datareq sends the corresponding data-PDU to all conference partners.
6.: 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.
7.: 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.
8.: a CPE that receives a leave-PDU removes the conference partner specified by the leave-PDU from the set of conference partners.
9.: 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 1999-11-18