The project must deliver a distributed client/server system for
. This system should give function that people
can use to cooperate. The functionality should largely be the same as
those of email or Usenet newsgroups (discussion groups). The server(s) should keep track of the information that
does not belong to a specific user in a central location. The
client programs must allow the user to make use of the system. The
clients should have a simple GUI (don't spend too much time on it).
The communication between the clients and the server must take place
through distributed objects, i.e. not by using a protocol directly.
A server must be able to work with multiple clients simultaneously.
Optionally (depending on your design) clients might communicate with other
clients or servers with other servers.
Each group chooses either email
Minimal requirements are:
- Users can register themselves and be removed.
- Users can send messages to other users.
- Users can read their own messages.
- The system keeps a list of messages that a user has read.
- Messages can be organised in
separate mailboxes that the user can
create and remove.
- (Only for a 3-person group) The user can manage an
addressbook. The address book can
also have group addresses (mailing lists).
- There are discussion groups (not necessarily with a hierarchical
- Users can create new discussion groups and remove them when they are
- Users can subscribe and unsubscribe to discussion groups.
- Users that are subscribed to a discussion group can read its
messages and post new messages in it.
- The system will maintain which messages has been read by each user.
- (Only for a 3-person group) Messages that have been read by all users can be removed (optionally
after some expiration time).
- (Only for a 3-person group) Discussion threads should be formed.
Of course it is allowed to add additional functionality.
Your system should give some attention to security. Users that want to
use the system should be authenticated, and no user should be allowed
to work with data for which he/she is not authorized. E.g. a user can
only see and change his own mailbox, except for the group
appointments. In the design document you have to describe how this will
In the final documentation of the project you must also explain what
are the dangers of hackers/crackers trying to enter your system
illegally (e.g. by connecting directly to sockets), and how this should
be protected. It does not have to be implemented, however.
- 03 Sep 2008