- Project Description
- Architecture
- An Outside Perspective
- Security Concerns
- Data/Information Requirements
This is an informal (and incomplete) description of the Group
Communication Server (GCS) system. The purpose of this document
is to trigger discussions.
The first problem encountered in this project was to find a subject
that would be reasonable enough to be reached within the resources
and time frame allocated, yet complex enough to allow each group to
fully demonstrate its own field of expertise.
The project consists in designing, verifying, validating, implementing
and testing a Group Communication Server, on top of M. Schmith's
Adaptive Communication Environment (ACE).
In a nutshell, a Group Communication Server (GCS) will allow the
multicasting of messages to members of a group. A group will be
created and destroyed as the need commands. Users will be permitted
to join and quit one or many groups. Messages will consist in a
variety of types (e.g. voice, video, text) that will be multicast
to the members of the group via different communication channels,
selected to suit the requirements of the group.
A Master Group Communication Server (MGCS) acts somehow like RPC:
it listens on a request channel and spawns a Group Communication
Server (GCS) on request. It may also list the existing GCS,
to permit one to select the group(s) to be joined.
-
NB
-
For technical reasons, it might be a good idea to give the MGCS the
authority of destructing the GCS. Actually, it would be more for
administrative purposes: maintenance of the server, destruction of
illicitly created GCS, overloading, long time inactive groups, etc..
The MGCS is notified by the GCS of its ending; this allow the GCS
list to be kept up to date.
Presentement, MGCS ne detruit pas de groupe. Le groupe fait toutes
les verifications necessaires a sa destruction, et avertis MGCS si
necessaire afin de tenir a jour la liste des groupes, info que seul
MGCS possede.
Il est plus facile pour un GCS de prendre la decision car toutes les
information y sont incluses.
- Note
-
Administration of a group could be optional. Should this option
be modifiable on the fly?
A new GCS has only 1 member, namely the appointed administrator of
the group. If the appointed administrator unsubscribes, another
member is arbitrarily appointed administrator.
A more sophisticated procedure would be to forbid the unsubscription
of the administrator, hence effectively forcing him/her to first
appoint a new administrator before leaving the group. This might
become necessary if it is decide to allow GCS to exist without
administrator.
- Note
-
We might impose on the current administrator to elect a new one
before leaving the group (via ChangeAdmin).
Each GCS is independent of the other ones; it has its own channel to
receive requests (multicast, register, deregister, list members,
delete the group, change admin). It will die if either a
specific request for its destruction is received (and permision
is verified) or there is only 1 member left in the group after
someone unsubscribed.
- Note
-
Currently, a group auto-destruct only when there's noone
left in the group.
-
NB
-
To make things interesting, a CLIENT could be created to allow a
nicer simulation. This may also be necessary to define the behaviour
of the client!
The medium should not be limited to text (i.e. voice, video, sound).
This would require the use of various means of transmission:
- streamed (e.g. audio/video)
- connection-oriented (e.g. IRC)
- connectionless (e.g. stock market information)
- using third-party services (e.g. e-mail)
This would also require different GCS initiation and
subscription procedures.
The creation and subscription procedure would then have to tailor the
details of the type of communication channels to be used; and ensure
that the information to "connect" to each subscriber is provided.
- Note
-
Currently, there may be a "canal type" specified within the
attributes of the group. At subscription time, members provide there
CID (Channel Identifier) in conformity with the type of the channel
of the group. Making the list of members a 2-tuple: {MID, CID}.
Those characteristics are currently there but used only for multicast.
- mgcs_chnl: Master Group Communication Server Channel
- gcs_chnls: Group Communication Server Channels
- out_chnl: mean of distributing messages to group members
Here are the principal components of the GCS, as they could be
percieved by the users.
In all cases, only the members of a group receive messages
from that group.
Possible types of groups:
- Subscription
-
- public
- anyone can register (e.g. mailing lists)
- private
- admin (or moderator? or members??) must register another
one (e.g. telephone conference)
- Multicasting
-
- opened
- anyone can send (e.g. mailing lists)
- closed
- must be member to send (e.g. IRC)
- moderated
- must be moderator to send
(e.g. moderated list; conference animator)
- Note
-
Abstract Data Types will be used to handle those
characteristics, via guards and predicates.
-
Question
-
Should groups be possibly un/moderated? E.g. filtering of
mailing
lists; selection of priority in audio/video conference.
I.e. any message
received by anyone else but the moderator is resent right
back to the
moderator. Only messages coming from the moderator are
multicast.
-
NB
-
When a group is destructed, inform the remaining subscribers
(if any); and if it is pertinent to do so.
E.g. "connection-oriented" would benefit from some
'end-of-transmission' message, but "mailing-list" could be
taken care of by the application (mostly since those would be
of the kind "connection-less).
-
NB
-
A recovery procedure might allow a MGCS to be restarted and
obtain the information of the surviving GCS (from them!).
Administrator
By default, the member who created the list.
Privileges: to delete the list; to add & remove users.
-
NB
-
The administrator might be elected in case where the current one
unsubscribes (instead of being appointed). The admin might be
refused unsubscription (i.e. s/he'd have to see to elect/appoint
another admin first!).
Moderator
Decides upon which messages are to be multicast. S/He may also
be attribute the privilege of adding/removing group members
-
Question
-
Should anyone be eligible to the privilege of adding users?
Ordinary members
- may unsubscribe
- may receive messages from the GCS
- may send messages to the GCS
Not members
- may subscribe (if the group is opened)
- may send messages to the GCS (if the group is public)
-
the admin for the destruction of the group; moderation
-
the admin for moderation
-
any subscriber who wishes to submit a message for multicast
(in the case of closed groups);
- to ensure only valid GCS will be accepted by subscribers
-
Question
-
Should unreliable medium be considered? Or planned as expansion?
Shouldn't that be left to the transport layer?
-
Question
-
What happens to a message sent to a GCS that does not exist?
-
Question
-
What happens when the MGCS dies?
-
Question
-
What happens when a GCS dies?
-
Question
-
What happens when a subscriber dies?
- A list of members
- A list of GCS
Group Creation
- the requestor (admin, by default)
- group ID
- group description, purpose
- Multicasting Type (medium: mail, sockets; data: text, video, sound)
- characteristics: administrated or not; un/moderated
-
NB
-
At subscription, CID is provided (specific to the multicasting type).
Group Deletion
- the requestor (=def= admin)
- group ID
Group Subscription
- group ID
- the requestor ID
- specifics of the multicasting type (requestor's host, IP, socket)
according to group requirements.
Group Unsubscription
- group ID
- the requestor ID
List Group Members
- group ID
- the requestor ID
List Groups
Multicast
- the message
- the sender ID
- the group ID
Change of administrator
- group ID
- the requestor ID (must be admin)
- the ID of the new admin
Daniel Amyot and Jacques Sincennes