CHIRC / IRC

Université de CAEN
Campus II
UFR Sciences
Département d’Informatique
Master 1 Informatique
PROJET DE PROGRAMMATION AVANCEE DES SYSTEMES
ET DES RESEAUX
UE 10
« SALON DE DISCUSSION »
- CHIRC / CHATIRC -
AUBRUN Thibaut
LION Thomas
MAUDOUIT Ludovic
VIARD Philippe
Responsable de Projet :
M. MADELEINE Jacques
Rapport de Projet
soutenu Mai/Juin 2005
SOMMAIRE
INTRODUCTION
2
I.
3
II.
ARGUMENTATION DE NOS CHOIX
1. Généralités
3
2. Nos fichiers
4
3. Nos commandes
6
DEFINITION DES PROTOCOLES
PROTOCOLES - RFC
7
1. Introduction
8
2. Le modèle
8
3. Les procédures
8
4. Les spécifications
11
5. Le glossaire
11
III. EXEMPLES DE SCENARII D’UTILISATION
13
CONCLUSION
17
1
INTRODUCTION
NTRODUCTION
Le but du devoir est de réaliser une application de type « salon de discussion » (chatroom).
Cette application comportera plusieurs programmes communiquant via un réseau.
Un utilisateur pourra « entrer » dans un salon de discussion et y communiquer avec les autres
utilisateurs présents.
Dans le salon, les discussions seront publiques. Toutefois, les utilisateurs auront aussi la
possibilité de créer des conversations privées.
Une conversation fait intervenir au moins deux utilisateurs. Il n’y a pas de maximum théorique au
nombre d’utilisateurs (il peut évidemment y avoir un maximum technique).
Un utilisateur pourra participer à plusieurs conversations simultanément.
La création d’une conversation privée et la participation d’un utilisateur à une telle conversation
seront régies par des règles précises qu’il vous incombe de décrire.
Dans une version plus avancée, plusieurs salons, géographiquement distribués, pourront se
regrouper pour permettre à un utilisateur de participer aux conversations qui y ont lieu.
2
I. ARGUMENTATION DE NOS CHOIX
1. Généralités
Notre projet a été effectué premièrement en Java. Nous avons décidé de le réaliser également en
C++.
•
Afin de rendre compatible notre programme dans divers langage nous avons interfacé la
partie réseau de notre projet en Corba. Tout ce qui concerne Corba se trouve dans les
fichiers : ChatRoomImpl.java et ChatUserImpl.java.
•
L’IDL définie les interfaces ChatRoom et ChatUser.
Nous utilisons les options de compilation de l’IDL : -fallTIE -oldImplBase afin de créer des
objets « TIE ». Cela remplace le PAO et facilite l’utilisation de l’IDL. Nous ne sommes en effet
pas obliger de créer une classe Servant et nous pouvons instancier nos classes par l’intermédiaire
des objets « TIE ». Voici à quoi ressemble notre IDL :
module app{
typedef sequence<wstring> SeqString;
interface ChatUser {
void put(in wstring msg, in wstring salon);
wstring getPseudo();
void setTabUsers();
wstring getSalonActif();
void askMeToCreateMP(in wstring avecqui, in wstring nomMp);
void setSalon();
};
interface ChatRoom {
void post(in wstring msg,in wstring pseudo, in wstring salon);
boolean subscribe(in ChatUser u, in wstring pseudo);
void unsubscribe(in wstring pseudo);
wstring getUsers(in long index, in wstring pseudo);
wstring getSalon(in long i, in wstring pseudo);
boolean connectSalon(in wstring salon,in wstring pseudo);
void pleaseCreateMP(in wstring avecqui, in wstring dequi, in wstring
nomMp);
boolean isHere(in wstring salon, in wstring pseudo);
};
};
•
Pour le service de nommage on utilise ORBD, notre programme fonctionne également
sous OMNI mais on ne s’est servi que d’ORBD.
3
•
Pour la couche transport nous avons utilisé TCP. Concrètement quand un utilisateur
souhaite poster, son message est envoyé au serveur. C’est le serveur qui se charge ensuite
de rediriger le message sur le bon salon. Si par exemple l’utilisateur n’a pas le droit de
poster (amélioration possible) alors son message ne sera pas affiché par le serveur ! Dans
le cas contraire, le serveur acquitte le message en renvoyant au client concerné son
message.
•
Pour l’interface graphique nous nous sommes servi de Java et plus particulièrement des
JPanel.
Nous disposons de cinq principaux JPanel disposé géographiquement grâce à un BorderLayout
avec les paramètres North, South, West, Center, East.
Ainsi le GridLayout qui regroupe la liste des salons est dans West, le GridLayout qui regroupe la
liste des utilisateurs est dans East, le panneau central JTextArea où s’affiche les messages est dans
Center, la barre où l’utilisateur entre son message et peut l’envoyer et dans South et l’affichage du
salon actif est dans North.
Les simples textes comme « pseudo », « salons » sont de simples JLabel.
Nos divers salons et pseudos d’utilisateurs (dans leur panel respectif) sont en fait des JButton,
comme le bouton « Send », permettant ainsi de pouvoir s’en servir en un simple clic.
2. Nos fichiers
Notre programme en Java est composé de 5 fichiers, nous allons détailler ici ces fichiers ainsi que
les fonctions qui les composent (les fonctions « triviales » ne sont pas explicitées) :
•
ChatRoomImpl.java : fichier qui regroupe tout ce qui concerne la gestion du « chatroom »
en général, ainsi que le lien avec Corba. Ce fichier contient entre autre les fonctions :
-
unsubscribe : permettant de déconnecter un utilisateur des salons
-
miseAJourSalonUsers() : met à jour la liste des utilisateurs ainsi que les salons.
-
post (String msg, String pseudo, String salon) : fonction qui gère l’affichage des
messages appelés « posts » ainsi que les diverses commandes de salon.
-
getSalon(int i, String pseudo) : renvoie le salon courant.
-
getUsers(int index, String pseudo) : retourne la liste de tous les utilisateurs du chat.
-
pleaseCreateMP(String avecqui, String dequi, String nomMp) : permet d’activer la
gestion des messages privés.
-
connectSalon(String salon, String pseudo) : connecte un utilisateur à un salon.
4
•
ChatUserImpl.java : fichier qui gère principalement toute l’interface graphique du
programme (nous ne développons pas ici ses fonctions) ainsi que quelques autres
fonctions :
-
put(String msg, String salon) : gère l’affichage des diverses commandes.
-
isMP(String salon) : teste si le salon courant est un salon privé.
-
setSalon() : permet l’affichage des salons.
-
setTabUsers() : permet l’affichage des utilisateurs.
-
askMeToCreateMP(String avecqui, String nomMp) : affichage d’une fenêtre de
messagerie privée au destinataire du « mp », par le serveur.
-
createMP(String avecqui) : permet de créer une conversation privée (salon privé).
-
deleteMP(int i) : supprime le salon privé.
-
inscription(String args[]) : fonction complexe qui gère les liens de notre application
avec Corba.
•
GestionSalon.java : fichier qui gère tout ce qui se rapproche aux salons, comme joindre,
créer un salon, se déconnecter etc.
-
belongSameSalon(String salon, String pseudo) : teste si un utilisateur appartient ou non
à un salon donné.
-
connectSalon(String salon, String pseudo) : ajoute un utilisateur aux salons.
-
changeNick(String lastpseudo, String newpseudo) : pour tous les salons dans lesquels
l’utilisateur est connecté, change son pseudo.
-
createSalon(String salon) : permet la création d’un salon.
-
deconnect(String salon, String pseudo) : fonction qui déconnecte et supprime un
utilisateur d’un salon.
•
MessagePrivé.java : fichier regroupant ce qui concerne les salons privés/messages privés
(mp) ainsi que l’interface graphique de ceux-ci.
-
put(String msg) : affiche le message a l’écran.
-
setPseudo(String _pseudo) : gère un changement de nom par exemple.
•
Salon.java : permet de créer un salon
-
userBelongOn(String pseudo) : teste si un utilisateur est présent ou non.
-
changeNick(String lastpseudo, String newpseudo) : pour le salon courant, change le
pseudo de l’utilisateur s’il est connecté.
5
•
CenteredDialog.java : Fichier qui permet d’afficher la première fenêtre de dialogue du
programme nous demandant d’entrer notre pseudo. Ce fichier est appelé, il n’a pas été
réellement créé par nos soins.
3. Nos commandes
Nous avons créés plusieurs commandes facilitant l’utilisation de notre salon de discussion. Nous
allons voir l’utilisation et le fonctionnement de chacune d’elles :
•
Les commandes sont des mots de quatre lettres précédés d’un « / ». Les commandes
s’écrivent en minuscules.
•
Elles permettent l’utilisation de notre programme en mode console et facilitent son
utilisation en mode graphique.
•
Notre programme contient :
-
/msgp <dest> <msg> : permet d’envoyer un message privé (plus couramment appelé
« mp ») à un autre utilisateur connecté.
-
/msga <msg> : permet l’envoi d’un message a tous les channels/salons sur lequel
l’utilisateur est connecté (hormis les discussions privées évidemment).
-
/nick <nick> : permet à l’utilisateur de changer de pseudo. Ce changement de pseudo
n’intervient pas dans les conversations privées.
-
/join <channel> : permet à l’utilisateur de rejoindre le salon « channel ».
-
/quit <channel> : permet à l’utilisateur de quitter le salon « channel ».
-
/disc : déconnecte l’utilisateur de tous les salons et lui fait quitter l’application.
-
/msgc <channel> <msg> : permet tout simplement à l’utilisateur d’envoyer un message
dans le salon « channel ».
-
/ltu_ : affiche la liste de tous les utilisateurs connectés dans tous les salons.
-
/ltc_ : affiche la liste de tous les salons.
-
/ltuc : affiche la liste des utilisateurs présents dans le salon « channel ».
6
4. Diagramme de classes
7
II. DEFINITION DES PROTOCOLES
PROTOCOLES – RF
RFC
1. Introduction
Le but du protocole de notre salon de discussion est de transférer des messages selon un
procédé simple et efficace. Ce protocole pourra gérer les principales fonctions que possède un
IRC. Il est possible d’envoyer un message sur un salon, à un utilisateur ou encore de faire un
broadcast. La création, la connexion et la déconnexion à un salon, sans oublier de lister tous
les utilisateurs et les salons existants sur le serveur sont implémentées.
2. Le modèle
Les applications sont basées sur le protocole TCP. Le serveur écoute sur le port 2810 afin de
pouvoir utiliser le service de nommage. Une fois la connexion établie, l’application utilise
Corba pour l’envoie et la réception des messages.
3. Les procédures
Cette section présente les différentes procédures utilisées dans notre protocole.
/msgp <sp> <DEST> <sp> <MSG> <CRLF>
Cette commande indique qu’un message peut être envoyé à un destinataire sous forme d’un
message privé.
/msga <sp> <MSG> <CRLF>
Cette commande indique qu’un message est envoyé à tous les salons sur lesquels l’utilisateur
est connecté
8
/msgc <sp> <CHANNEL> <sp> <MSG> <CRLF>
/msgc permet d’envoyer le message « MSG » au salon « SALON »
/nick <sp> <NICK> <CRLF>
La commande /nick permet à l’utilisateur de changer de nom.
Si la commande est envoyée par le client sans erreur, le serveur la lui renvoie. Sinon un
format de commande est envoyé au client par le serveur.
/join <sp> <CHANNEL> <CRLF>
/join permet à l’utilisateur de rejoindre ou de créer un salon « CHANNEL ».
Si le client envoie la commande sans erreur, le serveur la lui renvoie. Sinon il renvoie le
format nécessaire au bon déroulement de la commande.
/quit <sp> <CHANNEL> <CRLF>
Cette commande permet de quitter le salon « CHANNEL ». Si la commande est réussie par le
serveur alors elle est renvoyée au client. Le client change de salon actif, si celui-ci est le salon
a quitté.
/disc <CRLF>
/disc déconnecte l’utilisateur de tous les salons et quitte l’application.
/ltu_ <CRLF>
Cette commande affiche la liste des utilisateurs connectés sur le serveur.
/ltc_ <CRLF>
/ltc_ affiche la liste de tous les salons présents sur le serveur.
9
/ltuc <CRLF>
Cette commande permet l’affichage de la liste des utilisateurs du salon courant.
/err_ <sp> <CMD> : <MSG> <CRLF>
Cette commande est renvoyée par le serveur lorsqu’il rencontre une erreur lors de l’exécution
de la commande <CMD> et joint le message <MSG> expliquant l’erreur.
Exemple 1/ Exemple de procédure de création de salon.
Cet exemple de séquence montre la création d’un salon discussion « Warcraft3 » :
S: /join Warcraft3
R: /join Warcraft3
La création du salon Warcraft3 est accepté : en effet la réponse /join Warcraft3 par le
serveur veut bien dire que la création a bien été faite.
Exemple 2/ Exemple de procédure de discussion privée.
Cet exemple de séquence montre une discussion privée demandé par Toby, utilisateur de
l'hôte Alpha, à Sonia utilisateur de l'hôte Beta. Nous supposerons que l'hôte Alpha contacte
l'hôte Beta directement.
S: /msgp Sonia Salut Toby
R: /msgp Sonia Salut Toby
S: /msgp Toby Salut ma ptite Sonia !!!
R: /msgp Toby Salut ma ptite Sonia !!!
S: /msgp Sonia Ca va ?!
R: /msgp Sonia Ca va ?!
10
S: /msgp Toby :-)
R: /msgp Toby :-)
La réponse par le serveur /msgp Sonia Salut Toby veut bien dire que le message a
bien été envoyé.
4. La spécification
SEMANTIQUE DES COMMANDES
Nos commandes sont des chaînes de caractères terminées par une séquence <CRLF>. Les
codes de commande eux-mêmes sont constitués d'une séquence de digits en mode texte
terminée par un <SP> lorsque des paramètres suivent, sinon par <CRLF>.
SYNTAXE DE COMMANDES
Les commandes consistent en un code de commande suivi d'un champ d'argument. Les codes de commande sont
constitués de quatre caractères alphabétiques ou de trois caractères alphabétiques et d’un « _ ». Il est tenu compte
de la casse pour le code de commande. Ainsi, seul les écritures en minuscule de toutes les commandes sont
acceptées.
5. Glossaire
Utilisateur
Un être humain (ou un programme sous contrôle d'un être humain) désirant utiliser le service
de messagerie. Par extension, un récipiendaire de message sur un hôte.
<CRLF>
La séquence constituée du caractère Retour Chariot (code 13) et du caractère Nouvelle ligne
(code 10).
<SP>
Le caractère espace (code 32 de l'ASCII).
11
Mot
Une séquence de caractères imprimables.
Message
Une séquence de caractères ASCII de longueur arbitraire, conforme aux spécifications du
document "Standard for the Format of ARPA Internet Text Messages" (RFC 822 [2]).
Commande
Une requête émise par un émetteur pour déclencher l'exécution d'une action par un récepteur.
Hôte
Une machine située sur un réseau interconnecté hébergeant un salon de discussion.
12
III. EXEMPLES DE SCENARII D’UTILISATION
Ici on voit la fenêtre telle qu’elle s’affiche au
lancement de notre programme.
On remarque la petite fenêtre invitant
l’utilisateur à entrer le pseudo et le listing des
salons et des pseudos en arrière plan.
Le JLabel « nick Name » ne contient pas le
pseudo de l’utilisateur étant donné que
l’utilisateur n’est pas encore connecté au
serveur.
Sur
cette
l’utilisateur
image
a
tapé
/join StarWars.
On observe donc que
son pseudo s’affiche
dans le salon
StarWars et que le
salon StarWars
apparaît dans le
listing des salons.
Un label lui indique
également le salon
dans lequel il discute.
13
Sur ce screenshot,
on observe une
discussion entre
deux utilisateurs
dans le salon
« Cinema ».
L’utilisateur Toby
est connecté à
divers salons
affichés dans son
listing.
On observe que Filou a tapé la commande /ltuc, le serveur affiche donc le listing des
utilisateurs dans le salon courant.
Lorsqu’il n’y a plus d’utilisateurs dans un salon alors ce dernier se détruit automatiquement.
14
L’utilisateur « Fxl » a changé
de pseudo et s’appelle
maintenant « Ludo ».
Après avoir fait un listing des
utilisateurs on voit que
« Ludo » apparaît à la place
de « Fxl ».
Sur ces deux images on peut lire la conversation entre deux utilisateurs en message privé.
Chaque utilisateur a bien évidemment sa fenêtre !
Cette discussion s’effectue dans le salon « TobyFxl » (le salon se nomme en fait avec les deux
pseudos qui discutent mis bout-à-bout). Ce salon est bien évidemment disponible dans la liste
des salons des deux utilisateurs (voir screenshot précédent).
15
CONCLUSION
Réaliser une application complète en Java (client et serveur) et qui fonctionne a été notre priorité
tout au long de notre programmation. Au vue du nombre de fonctions, débuguer le programme n’a
pas été chose simple. De plus les diverses commandes pour lancer serveur, client, orbd etc. ne
nous ont guère facilité la tâche !
L’interface graphique ne nous a pas excessivement pris de temps (Java est vraiment intuitif) mais
faire le lien entre elle et le code n’a quand même pas été chose simple ! L’actualisation de cette
interface en fonction des diverses fonctions utilisées en arrière-plan ne fût pas facile.
Vous trouverez à cette adresse : http://users.info.unicaen.fr/~pviard/UE10/chIRC/ notre projet.
RESPONSABILITE DE CHACUN DES ETUDIANTS
La majeure partie de notre travail s’est effectuée en groupe.
Cependant chacun d’entre nous a eu une tache à s’occuper plus particulièrement.
Thibaut a eu en charge la majeure partie Java/Corba du projet, à savoir la réalisation du client et
du serveur.
Thomas s’est occupé de la RFC et de l’IDL ainsi que de l’interface graphique avec Ludovic.
Ludovic a donc réalisé le rapport ainsi que l’interface graphique (Java) avec Thomas.
Philippe a réalisé le client et le serveur en C++ ainsi que la gestion des commandes pour se servir
du logiciel (les commandes utilisables telles que /quit /join etc.)
La majeure partie de réalisation de notre travail a été la conception du projet en Java. Tout le
monde a participé à cette réalisation même si Thibaut en a été le « chef d’orchestre ».
La réalisation de notre programme en C++ n’est pas totalement finie. Nous avons rencontré plus
de problèmes entre Corba et C++ qu’entre Corba et Java. Nous avons préféré axer notre travail sur
16
la réalisation d’une application Java qui fonctionne. Nous espérons cependant qu’elle sera finie
pour le jour de notre soutenance.
La réalisation de la RFC fut assez longue et nous a pris pas mal de temps.
AMELIORATIONS POSSIBLES
Par manque de temps nous n’avons pas réalisé toutes les optimisations que nous aurions souhaité
faire.
Par exemple, il faut être connecté à un salon pour pouvoir lire les messages de ce salon. Si un
utilisateur va dans le salon « ciné » il ne pourra pas lire les messages écrits par des utilisateurs
dans le salon « musique » sauf s’il s’est auparavant connecté à ce salon. Avec du temps, on aurait
pu, soit gérer un historique des messages de chaque salon et ensuite afficher les messages du salon
dans lequel l’utilisateur est connecté (trier les messages en fait), soit gérer un panel pour chaque
salon, puis switcher entre les divers panels quand l’utilisateur change de salon, ces deux solutions
permettent de mieux suivre une conversation entamée sur un salon.
De plus, nous n’avons pas géré le « multi-serveur », à savoir que plusieurs serveurs puissent se
connecter entre eux afin de mettre en commun leurs salons et leurs utilisateurs.
De même nous n’avons pas d’ « opérateurs », ces utilisateurs qui administrent les salons. Nous ne
gérons pas les droits des utilisateurs. N’importe qui peut donc créer un salon, un message privé
etc. Un utilisateur gênant ne peut donc pas non plus être « kické » (exclu) !
Evidemment plusieurs autres améliorations sont possibles, cependant elles restent assez
« gadgets », comme par exemple la gestion des avatars des utilisateurs, les couleurs dans les
messages etc. Des améliorations sur la beauté du programme en quelque sorte.
De plus nous manquons légèrement d’affichage de renseignements. Par exemple lorsqu’un
utilisateur change de pseudo, il aurait été sympathique qu’un message s’affiche à l’écran (dans le
panel des messages).
17