Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop

République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université AMAR TELIDJI Laghouat
FACULTE DES SCIENCES ET DE L’INGENIERIE
DEPARTEMENT DE GENIE INFORMATIQUE
Mémoire de fin d’études
Pour l’obtention du diplôme d’ingénieur d’état en informatique
Option : Systèmes Parallèles et Distribués (SPD)
Thème :
Étude et réalisation d’une application de
contrôle d’un PC à distance en
Réalisé par :
BENYAMI Bachir
HASSANI Mustapha
Suivi par :
Mr. BENSAAD Mohamed Lahcen
N° d'ordre; ….. 2008-PFD / DGI

Remerciements
Nous tenons à remercier en premier lieu notre Dieu qui nous a
donné la santé, la force et le courage pour mener à bien l’étude et
l'implémentation de ce projet.
Aussi, Nous remercions chaleureusement nos parents, qui nous
ont beaucoup aidé matériellement et moralement, depuis notre enfance
et jusqu’à ce que nous sommes arrivés à ce point là. Sans oublier aussi
nos sœurs, nos frères et nos familles.
Nous tenons à remercier notre encadreur Mr. Mohamed Lahcen
BENSAAD pour son dévouement et la confiance qu’il nous a accordé
pour la réalisation de ce travail. Sa persévérance, son enthousiasme et
sa générosité nous ont été d’un grand soutien dans notre travail.
Nous tenons à remercier tous nos enseignants qui ont contribué à
notre formation, particulièrement Mr. Youcef OUINTEN, Mr. Kamel
BOUKHALFA, Mr. Taher ALLAOUI.
Nous remercions le président du jury Mr. LAGRAA Nacereddine
et l'examinatrice Mademoiselle BELABASSI Amel pour leurs acceptation
d'examiner ce mémoire.
Nous tenons enfin à remercier toutes les personnes qui nous ont
aidé de prés ou de loin à compléter ce travail notamment Mr. Yacine
DOUAG et Toufik FEKHAR qui nous ont aidé dans la phase du test du
jrdesktop sur Internet.
Ce travail est dédié à la mémoire de notre ami Bachir KERROUCHI.

Résumé
Un des plus grands challenges de cette décennie est sans aucun doute le bureau distant car il
s’articule autour de plusieurs points notamment le contrôle, la maintenance, la sécurité et
l’évolutivité. Ces différents points montrent l'importance du contrôle à distance dans un réseau
étendu composé de plusieurs réseaux locaux. Au niveau professionnel, le bureau à distance paraît
un outil indispensable pour maintenir la rapidité, l'efficacité et la sécurité d'un réseau étendu. Le but
de ce projet de fin d’étude est de concevoir et de réaliser une application de bureau à distance pour
des diverses utilisations qui s exécutent à distance via le réseau local ou mondial tel que la
télémaintenance, la téléintervention et la formation à distance, etc. Pour ce faire, nous découpons
l'architecture conceptuelle de notre système en quatre volets majeurs. Le bureau distant représente
le premier volet fournissant une étude générale sur la description, le fonctionnement, la mise en
place et les domaines d’utilisation. Le second volet concerne le langage de programmation Java,
ainsi les outils et les technologies qu’on a utilisés durant la réalisation de notre application. Le
troisième volet est consacré à la description, la conception et l’implémentation de notre système
surnommé « jrdesktop » en utilisant le langage de modélisation UML. Le dernier volet assure le
déploiement du système conçu, dont on montre la vue générale de l’IHM et comment utiliser le
système, on montre aussi une étude de qualité du logiciel, ainsi des tests et les résultats de ces tests
qui ont été faits sur le transfert des données entre le contrôleur et le contrôlé. On finit par
représenter une vue générale sur les sites web qui ont publié notre logiciel et des statistiques de
téléchargement de notre application hébergée sur le site web de jrdesktop.sourceforge.net.
Mots clés : Bureau distant, VNC, RDP, RMI, SSL, jrdesktop

Abstract
One of the biggest challenges of this decade is undoubtedly the remote desktop because it
revolves around several points in particular control, maintenance, safety and evolutionary. These
various points show the importance of remote control in a wide area network composed of several
local area networks. At the professional level, the remote desktop seems an indispensable tool for
maintaining the speed, efficiency and safety of a wide area network. The aim of this final project
study is to conceive and implement an application of remote desktop for various uses that are made
remotely via the local network or wide such as remote maintenance, the intervention at a distance
and training distance, etc To do this, we cut conceptual architecture of our system into four major
parts. The remote desktop represents the first phase providing a general study on the description,
operation, establishment and the fields of use. The second part concerns the Java programming
language and the tools and technologies that are used during the realization of our application. The
third part is devoted to the description, design and implementation of our system nicknamed
"jrdesktop" using the modeling language UML The last component ensures the deployment of the
designed system, which shows the general view of the GUI and how to use the system, it also shows
a study of software quality, and testing and results of these tests which were made on the transfer
data between the controller and controlled. It eventually represents an overview on the websites that
have published our software and the statistical software and download our application hosted on the
jrdesktop.sourceforge.net web site.
Key words: Remote desktop, VNC, RDP, RMI, SSL, jrdesktop.

Table des matières
I
Table des matières
INTRODUCTION GENERALE ................................................................................................................................. 1
1. INTRODUCTION.................................................................................................................................................... 3
2. PRESENTATION DU BUREAU DISTANT.......................................................................................................... 4
3. TERMES LIES AU BUREAU DISTANT ............................................................................................................... 5
4. DISPOSITIFS DE BUREAU DISTANT ................................................................................................................. 5
4.1. LE FACTEUR MATERIEL............................................................................................................................................... 5
4.2. LE FACTEUR RESEAU .................................................................................................................................................. 5
4.3. LE FACTEUR LOGICIEL ................................................................................................................................................ 6
4.4. LE FACTEUR SECURITE................................................................................................................................................ 6
4.5. LE FACTEUR MATERIEL............................................................................................................................................... 6
5. LE FONCTIONNEMENT DU BUREAU DISTANT.............................................................................................. 6
6. MISE EN PLACE .................................................................................................................................................... 7
6.1. PROBLEMATIQUES ET SOLUTIONS APPROPRIEES.......................................................................................................... 8
6.1.1. PC derrière un pare-feu ..................................................................................................................................... 8
6.1.2. PC derrière un routeur....................................................................................................................................... 8
6.1.3. Pas de connexions entrantes .............................................................................................................................. 8
6.1.4. Adresse IP dynamique........................................................................................................................................ 8
6.2. TECHNIQUES D'AIDE POUR ACCES A DISTANCE............................................................................................................ 8
6.2.1. DNS dynamique.................................................................................................................................................. 8
6.2.2. Redirection des ports.......................................................................................................................................... 9
6.2.3. Relai (ou répéteur) ........................................................................................................................................... 10
6.2.4. Tunnel http........................................................................................................................................................ 11
7. L'UTILISATION DU BUREAU DISTANT...........................................................................................................11
8. COMPARER DES DIFFERENTS LOGICIELS DE BUREAU A DISTANCE....................................................12
9. INCONVENIENTS DU BUREAU DISTANT........................................................................................................16
10. ADMINISTRATION ET CONTROLE PAR MOBILE.......................................................................................16
11. CONCLUSION .....................................................................................................................................................17
1. INTRODUCTION...................................................................................................................................................18
2. LE LANGAGE JAVA.............................................................................................................................................18
2.1. LES AVANTAGES DE JAVA......................................................................................................................................... 18
2.2. JAVA STANDARD EDITION 6 ..................................................................................................................................... 19
3. LA TECHNOLOGIE RMI (REMOTE METHOD INVOCATION).....................................................................19
3.1. APPLICATIONS DISTRIBUEES ..................................................................................................................................... 19
3.2. OBJECTIFS DE RMI ................................................................................................................................................... 20
3.3. L'ARCHITECTURE RMI............................................................................................................................................. 20
CHAPITRE I : LE BUREAU DISTANT
CHAPITRE II : OUTILS ET TECHNOLOGIES UTILISÉS

Table des matières
II
3.3.1. Interface ........................................................................................................................................................... 20
3.3.2. Les différentes couches de RMI........................................................................................................................ 21
3.4. PROCESSUS DE DEVELOPPEMENT D’UNE APPLICATION RMI .................................................................................... 23
4. LE PROTOCOLE DE SECURITE SSL ................................................................................................................25
4.1. DEFINITION DU PROTOCOLE...................................................................................................................................... 25
4.2.1. Architecture du SSL.......................................................................................................................................... 25
4.2.2. Fonctionnement du SSL.................................................................................................................................... 26
4.2. JAVA ET SSL............................................................................................................................................................. 28
4. NETBEANS ............................................................................................................................................................28
5. CONCLUSION .......................................................................................................................................................29
1. INTRODUCTION..............................................................................................................................................28
2. MODELISATION..............................................................................................................................................29
2.1. DIAGRAMME DE CAS D'UTILISATION................................................................................................................... 29
2.2. DIAGRAMME DE CLASSE..................................................................................................................................... 29
2.3. DIAGRAMME DE COMPOSANT............................................................................................................................. 30
2.4. DIAGRAMME DE DEPLOIEMENT .......................................................................................................................... 31
3. ARCHITECTURE DE L'APPLICATION ........................................................................................................32
3.1. ARCHITECTURE GENERALE................................................................................................................................. 32
3.2. ARCHITECTURE RMI.......................................................................................................................................... 34
3.3. COMMUNICATION ENTRE MODULES.................................................................................................................... 35
3.4. ARCHITECTURE DES MODULES ........................................................................................................................... 36
3.5. FONCTIONNALITES DE BASE ............................................................................................................................... 39
3.5.1. Transfert de données................................................................................................................................. 39
3.5.2. Serveur multihome .................................................................................................................................... 42
3.5.3. Multisessions............................................................................................................................................. 42
3.5.4. Sécurité ..................................................................................................................................................... 42
3.5.5. Capture d'écran ........................................................................................................................................ 43
3.5.6. Application des événements clavier et souris............................................................................................ 45
3.5.7. Qualité d'image JPEG .............................................................................................................................. 45
3.5.8. Compression de données........................................................................................................................... 46
3.5.9. Configuration............................................................................................................................................ 46
4. CONCLUSION...................................................................................................................................................46
1. INTRODUCTION...................................................................................................................................................47
2. ENVIRONNEMENT DE DEVELOPPEMENT.....................................................................................................48
3. UTILISATION DU SYSTEME ..............................................................................................................................48
3.1. PROCEDURE D'OBTENTION DE JAVA REMOTE DESKTOP............................................................................................ 48
3.2. INTERFACE UTILISATEUR (VUE GENERALE DE L’IHM).............................................................................................. 49
3.2.1. Fenêtre principale de jrdesktop........................................................................................................................ 49
3.2.2. Icône de la barre des tâches............................................................................................................................. 50
3.2.3. Menu contextuel ............................................................................................................................................... 51
3.2.4. Fenêtre de contrôle de l’application jrdesktop ................................................................................................ 51
CHAPITRE III : MODELISATION ET ARCHITECTURE
CHAPITRE IV : DEPLOIEMENT DU SYSTEME

Table des matières
III
3.3. CONFIGURATION DE MODULE HOTE ......................................................................................................................... 58
3.4. CONNEXION AU MODULE HOTE DEPUIS LE MODULE ADMIN ..................................................................................... 59
3.5. CONNEXIONS ACTIVES.............................................................................................................................................. 60
3.6. TRANSFERT DE DONNEES.......................................................................................................................................... 61
3.6.1. Transfert du contenu du presse-papiers........................................................................................................... 61
3.6.2. Transfert de fichiers et de dossiers................................................................................................................... 61
3.7. UTILISATION PAR LIGNE DE COMMANDE................................................................................................................... 62
3.8. MESSAGES D'ERREUR................................................................................................................................................ 63
4. ETUDE DE QUALITE DU LOGICIEL (EVALUATION)....................................................................................64
4.1. AVANTAGES DU LOGICIEL : ...................................................................................................................................... 64
4.2. LIMITATIONS DU LOGICIEL : ..................................................................................................................................... 65
4.3. TESTS ET RESULTATS DU TRANSFERT DE DONNEES ................................................................................................... 66
4.3.1. Envoie des données par le module Admin........................................................................................................ 66
4.3.2. Réception des données par le module Hôte...................................................................................................... 68
4.3.2. Transfert de fichiers ......................................................................................................................................... 69
4.4. COMPARAISON DU JRDESKTOP AVEC D’AUTRES LOGICIELS : .................................................................................... 70
5. JRDESKTOP SUR LE NET...................................................................................................................................74
5.1. SITE WEB DU PROJET JRDESKTOP SUR SOURCEFORGE.NET........................................................................................ 74
5.2. SITE WEB OFFICIEL DU PROJET .................................................................................................................................. 75
5.3. JRDESKTOP SUR WIKIPEDIA ....................................................................................................................................... 76
5.4. JRDESKTOP SUR GOOGLE CODE HOSTING PROJECT .................................................................................................. 77
5.5. JRDESKTOP SUR OHLOH ............................................................................................................................................ 78
5.6. JRDESKTOP SUR FREEBSD........................................................................................................................................ 78
6. CONCLUSION .......................................................................................................................................................78
CONCLUSION GENERALE.....................................................................................................................................79
GLOSSAIRE
ANNEXE A: TABLEAU DE BORD DU SITE WEB DU JRDESKTOP
ANNEXE B: DESCRIPTION DU DIAGRAMME DE CLASSE
BIBLIOGRAPHIE

Liste des figures et des tableaux
I
Liste des figures
Figure 1.1 -Les Applications du bureau distant 4
Figure 1.2 -Echange de données entre les module Admin et Hôte 7
Figure 1.3 -Accès à plusieurs serveurs VNC à l’aide d’un seul port 9
Figure 1.4 - Relai établit des connexions entre visualisateurs et serveurs VNC 10
Figure 1.5 - Diverses fonctionnalités d'echoServer 11
Figure 1.6 - Communication à l'aide d'un tunnel http 11
Figure 1.7 -Administration par mobile à l'aide de RDM + 15
Figure 2.1 -Architecture RMI 19
Figure 2.2 -les opérations de communication 21
Figure 2.3 -Invocation d’une méthode distante et renvoie de la valeur de retour 22
Figure 2.4 -SSL et ces sous protocoles dans le modèle TCP/IP 24
Figure 2.5 -Étapes d’établissement des connections SSL 25
Figure 2.6 -Interface de L’IDE NetBeans 6.0 27
Figure 3.1 - Diagramme de cas d'utilisation 29
Figure 3.2 - Diagramme de classe 30
Figure 3.3 - Diagramme de composants 30
Figure 3.4 - Diagramme de déploiement 31
Figure 3.5 -Schéma général d'une application de bureau distant 32
Figure 3.6 - Diagramme de paquetage 34
Figure 3.7 -Architecture RMI du jrdesktop 35
Figure 3.8 - Flux de données échangés entre modules 36
Figure 3.9 -L'architecture interne du module Viewer 37
Figure 3.10 - La structure interne du module Server 38
Figure 3.11 -Organigramme du transfert de données 40
Figure 4.1 -Apparence la fenêtre principale de jrdesktop 49
Figure 4.2 -Apparition de l’icône sur de la barre des tâches 50
Figure 4.3 -Le menu contextuel de jrdesktop 51
Figure 4.4 -Aperçu général de la fenêtre de contrôle à distance de l’utilisateur Admin 52
Figure.4.5 -barre d’outils de l’application 52
Figure 4.6 -Infos bulle explicative 53
Figure 4.7 -La sélection est en cours 54
Figure 4.8 -Après la sélection 54
Figure 4.9 -Affichage en plein écran 55
Figure 4.10 -Vue minime d'écran (échelle 1/2) 55
Figure 4.11 -Transfert d'une image à l'aide du presse-papiers 58
Figure 4.12 -Boîte de dialogue de configuration de module Hôte 59
Figure 4.13 -Etablissement des détailles pour connecter au module Hôte 59
Figure 4.14 -Consultation des PC Admin connectés en cours 60
Figure 4.15 -Détails de la connexion 60
Figure 4.16 -Propriétés de l'ordinateur distant 61
Figure 4.17 -La fenêtre du transfert de fichiers 61
Figure 4.18 -Affichage du l'aide du jrdesktop par la ligne de commande 63
Figure 4.19 -Exemple d'un message d'erreur 64
Figure 4.20 - PC sous Mac OS X 10.5.3 contrôle un PC sous Windows Vista 65
Figure 4.21 - L'effet de la compression sur les données envoyées 67
Figure 4.22 - Gain de la compression en pourcentage (%) 67
Figure 4.23 - Effet de la qualité de la compression d'image JPEG 68

Liste des figures et des tableaux
II
Figure 4.24 - Gain de la compression en pourcentage (%) 69
Figure 4.25 - Transfert de fichiers 70
Figure 4.26 -jrdesktop sur SourceForge 74
Figure 4.27 -Statistiques sur les téléchargements de jrdesktop 75
Figure 4.28 -Site web officiel du projet 76
Figure 4.29 -jrdesktop sur wikipedia.org 77
Liste des tableaux
Tableau 1.1 -Comparaison des diverses applications de bureau distant 13
Tableau 1.2 -Quelques applications de contrôle à distance par mobile 15
Tableau 3.1 - Diverses associations 33
Tableau 4.1 -Les différentes infos bulle inadéquates les divers événements 50
Tableau 4.2 -Les déférents changements de l’icône de la barre des tâches 51
Tableau 4.3 -Les composants de la barre d’outils et leurs activités 53
Tableau 4.4 -Comparaison des différentes palettes de couleurs 56
Tableau 4.5 -Comparaison de la qualité de la compression d'image JPEG 57
Tableau 4.6 -Les messages d'erreurs les plus fréquentés du jrdesktop 64
Tableau 4.7 -Comparaison générale 72
Tableau 4.8 -Comparaison détaillés 73
Tableau 4.9 -Statistiques sur les sources d'accès au site officiel du jrdesktop 75

Introduction générale
1
Introduction Générale
« Fort heureusement, chaque réussite est l'échec d'autre chose. »
Jacques Prévert.
Pendant ces dernières années, on a assisté à un développement fulgurant et une
prolifération d’applications spécialisées pour réseau dans la transmission de données par
Internet. Chaque jour apparaissent de nouvelles applications qui se déroulent à distance pour:
vidéoconférence, helpdesk, enseignement à distance, maintenance, reconfiguration,
télétravail, réparation, aide ...etc. La liste est longue et ne cesse de grandir. Les conditions de
service associées à ces applications diffèrent de celles des applications dites « élastiques »
(email, web, partage de fichier,...) car les exigences de service de ces applications multimédia
reposent sur deux axes: la synchronisation et la tolérance à la perte de données. Le bureau à
distance (ou Remote Control en anglais) fait partie de ces applications multimédia.
Aujourd'hui, la grande majorité des responsables informatiques ont pris conscience de
l'intérêt des dispositifs de bureau distant. En effet, pour que les entreprises répondent à leurs
défis surtout en ce qui concerne la continuité de l’activité et la rentabilité, elles doivent
dorénavant s’orienter vers cette approche stratégique qui répondra à la demande croissante
des utilisateurs, soutient les initiatives stratégiques et garantit la réactivité informatique,
indispensable à toute organisation efficace. Le bureau distant est une solution puissante
garantissant la sécurité de l’accès, la mobilité des utilisateurs et la mise à disposition des
applications à tout moment et à n’importe quel endroit.
Dans ce contexte, notre objectif est de réaliser une application de bureau à distance
qui soit capable d’apporter un aide quelconque à un utilisateur se trouvant dans le réseau local
(LAN), ou dans un autre lieu de la planète, et ce par le biais de l’internet comme si vous étiez
à sa place. Autrement dit, si vous êtes sur un poste et votre collègue sollicite votre aide, vous
pouvez, par le biais du réseau local, lui apporter votre aide grâce à cette application, en
installant celle-ci du côté serveur (le poste de votre collègue) appelé aussi hôte (ou host), et
sur le côté client (votre poste) appelé Admin (appelé aussi "guest") ainsi vous avez une accès
dans une fenêtre de l'écran distant où vous pouvez utiliser clavier et/ou souris sans problème
en vue d’intervenir sur le poste distant.

Introduction générale
2
Le bureau distant présente une solution idéale pour offrir une assistance à distance
rapide et aider vos clients, vos collègues, vos amis, ou toute autre personne, même s'ils sont à
l'autre bout du monde.
Ce mémoire est composé de 4 chapitres :
Dans le premier chapitre, nous avons défini le bureau distant et nous avons étudie ses
dispositifs, son fonctionnement et sa mise en place ainsi que ses utilisations. Dans le second
chapitre, on a intéressé à présenter le langage de développement Java et on a défini quelques
outils et technologies utilisés durant la réalisation de projet de fin d’étude. Le troisième
chapitre est consacré à la description, la conception et l’implémentation de notre système
bureau distant. Enfin, dans le dernier chapitre, nous avons présenté le système conçu pour
décrire l’environnement de développement, la manière d’utilisation du système, l’étude de
qualité et un aperçu sur les sites web qui ont publié notre logiciel surnommé « jrdesktop ».
Enfin nous avons présenté sous forme d’annexe une analyse faite par « Google
Analytics » sur le site officiel du notre logiciel jrdesktop.sourceforge.net, et un autre annexe
pour la description du diagramme de classe du notre projet.

CHAPITRE I Le bureau distant
3
Chapitre I
Le bureau distant
« C'est le commencement exact de notre fine »
William Shakespeare, le songe d'une nuit d'été. Acte V, scène I, ligne 111.
1. Introduction
Dans les années 90, les entreprises ont commencé à percevoir les avantages d’un accès distant à
leurs ressources, via le Web, pour leurs employés et partenaires. Pour parvenir à offrir un accès via
le Web, elles se sont alors tournées vers le bureau à distance qui est alors un moyen très efficace et
surtout pour les entreprises hautement informatisées.
Au niveau professionnel, le bureau distant paraît un outil indispensable pour maintenir le bon
fonctionnement d'un réseau étendu sans déplacement et aux moindres coûts.
Aujourd'hui, la grande majorité des responsables informatiques a pris conscience de l'intérêt des
dispositifs de bureau à distance.
Le bureau distant est un sujet assez vaste qui s'articule autour de plusieurs points :
· L'administration.
· Le contrôle.
· La maintenance.
· La sécurité.
· La mise à jour.
· ...

4
Ces différents points montrent l'importance du bureau à distance notamment dans un réseau étendu
composé de plusieurs réseaux locaux.
Dans ce chapitre on explique le bureau distant et on donne quelques termes liés à ce dernier. Puis,
nous allons étudier l'utilisation du bureau distant. Ensuite, on donne une comparaison des différents
logiciels de bureau à distance, ainsi, on cite quelques inconvénients. On finit par représenter
l’administration et le contrôle par mobile.
2. Présentation du bureau distant
Le bureau distant (ou bureau à distance) est un moyen qui permet l'observation et la prise de
contrôle d'un ordinateur distant (via Internet ou un réseau local) depuis l'écran d'un ordinateur local
dans l’objectif de maintenir, dépanner à distance, former et aider en ligne …etc. (Cf. Figure 1.1).
Figure 1.1 – Les Applications du bureau distant
Le bureau à distance vous permet d'utiliser votre écran, votre clavier et votre souris pour voir et
piloter l'ordinateur distant. Tous les mouvements de la souris et les signaux du clavier sont
transférés de l'ordinateur local directement à l'ordinateur à distance via le réseau LAN (local area
network), WAN (Wide area Network) ou Internet, relayant l'écran graphique, des mises à jour de
retour dans l'autre sens. Cela signifie que vous pouvez travailler et accéder à toutes les applications,
à tous les fichiers et à toutes les ressources réseau comme si vous étiez assis devant cet ordinateur à
distance, où que vous soyez. Le bureau distant permet aussi de piloter simultanément plusieurs
ordinateurs distants, depuis n'importe où dans le monde.
Le bureau distant prend en charge les connexions réseau sur un réseau local (LAN), un réseau
étendu (WAN) ou Internet. Il prend également en charge les connexions modem à modem et les
connexions directes (d'ordinateur à ordinateur) via un port série ou parallèle.

5
3. Termes liés au bureau distant
Il y a d’autres termes qui peuvent être confondu avec le terme bureau distant, chaque terme à sa
propre définition, son domaine d'utilisation et ses applications, parmi ces termes on cite :
§ Accès à distance ;
§ Contrôle à distance (ou commande à distance) ;
§ Administration à distance ;
§ Partage du bureau (en anglais Desktop Sharing).
4. Dispositifs de bureau distant
Le bureau distant s'effectuer simplement après avoir installé et configuré l'application. Mais pour le
faire efficacement et correctement, plusieurs facteurs sont indispensables pour savoir quels
matériels et quels outils sont nécessaires.
Le choix d'une solution par rapport à une autre se fera selon les besoins, les possibilités, les
avantages et surtout selon le coût [1].
4.1. Le facteur matériel
Un modem (modulateur-démodulateur), est un équipement réseau servant à communiquer avec des
utilisateurs distants.
Depuis la fin des années 90, de nombreuses normes de télécommunications sont apparues et, donc
autant de nouveaux types de modems : RNIS (Réseau Numérique à Intégration de Services), ou
ISDN (Integrated Services Digital Network), ADSL (Asymmetrical Digital Subscriber Line),
modem câblé, GSM (Groupe Spécial Mobile ou Groupe Système Mobile), GPRS (General Packet
Radio Service), Wi-Fi (WIreless FIdelity)…etc.
Parmi les technologies existantes de connexion à l'Internet, on cite [2] :
§ La connexion classique, par modem sur la ligne téléphonique : appelée 'RTC';
§ La connexion par ligne téléphonique haut-débit, de type RNIS;
§ La connexion par ligne téléphonique haut-débit, de type DSL : (Digital Subscriber Line,
abonnement téléphonique numérique);
§ La connexion par câble ;
§ La connexion par Wi-Fi.
4.2. Le facteur réseau
Les réseaux permettent de standardiser les applications, elles permettent aussi à plusieurs personnes
de travailler en réseau (Par exemple, la messagerie électronique et les applications de bureau
distant). Voici les avantages qu'offrent de tels systèmes :
§ diminution des coûts grâce aux partages des données et des périphériques;
§ standardisation des applications;
§ accès aux données en temps utile;

6
§ communication et organisation plus efficace.
On distingue parmi les différents types de réseau les LAN, MAN et WAN :
· Les LAN : local area network, sont les réseaux locaux. Les ordinateurs sont reliés dans une
petite zone géographique (soit avec des fils, soit sans fils).
· Les MAN (Metropolitan area Network) : permettent de connecter plusieurs LAN proches
entre eux.
· Les WAN : qui signifie réseau étendu, permettent de connecter plusieurs LAN éloignées
entre eux.
4.3. Le facteur logiciel
Une bonne application bureau distant demande de bonnes conditions pour qu’elle puisse fonctionne
efficacement. Ces conditions dépendent de type de modem utilisé (technologie de la connexion à
Internet), ainsi le type de réseau LAN, MAN ou WAN.
4.4. Le facteur sécurité
La plupart des fournisseurs de services proposent donc, en complément de la fourniture d'accès
permanents au réseau, des produits et des services pour protéger le réseau local. Les combinaisons
du filtrage, du chiffrement (pour la confidentialité et la sécurité des opérations), de
l'authentification et du contrôle d'accès aux outils et applications permettent de lutter sur l'ensemble
des points sensibles. Ces protections sont souvent basées sur le choix de technologies 'Firewall', qui
combinent ces différentes technologies [3].
La sécurité dans le bureau distant est très indispensable, car une application bureau distant peut
provoquer un espionnage pour le contrôleur contre le contrôlé au lieu que ce dernier devrait être
servi par aide ou dépannage.
4.5. Le facteur matériel
Un ordinateur puissant est mieux qu'un ordinateur moins puissant dans les applications d’accès à
distance notamment le bureau à distance dont la nécessité de l'envoi des captures d’écran en temps
réel de la part de poste contrôlé (Server), et l’envoi des touches claviers et mouvements souris de
la part de contrôleur (Viewer). La puissance est exprimée surtout en terme de vitesse de processeur
et de RAM (Random Access Memory).
5. Le fonctionnement du bureau distant
Pour la démarche de fonctionnement, vous devez avoir deux ordinateurs (ou plus) connectés à
travers le réseau local ou par Internet, et il faut installer l'application pour le bureau distant sur
chaque ordinateur.
La plupart des applications du bureau distant offrent en plus une connexion de type boucle de
retour (loopback).
Une application de type bureau distant est composée essentiellement de deux modules :

7
1. Module Admin (comme administrateur, appelé aussi "client", "visualisateur" (viewer) ou
l'ordinateur contrôleur) qui affiche le bureau et prend le contrôle de l'ordinateur distant en utilisant
le plan écran (ou une simple fenêtre), le clavier, et la souris de l'ordinateur local. En général, ce
module est installé uniquement sur le poste de l’utilisateur qui veut contrôler.
2. Module Hôte (appelé aussi "serveur", ou l'ordinateur contrôlé) qui exécute les commandes en
provenance du Module Admin et lui envoie l'état de son écran. Ce module doit être installé sur tous
les ordinateurs que l'on souhaite contrôler (ou même sur tous les ordinateurs du réseau local).
Le module Hôte peut agir comme un serveur http (HyperText Transfer Protocol), le module est mi
en écoute sur un port spécifique, le client utilise un navigateur en tapant l’adresse du serveur avec
le port associé (par exemple: http://192.168.1.221:5800), à l'établissement de la connexion, une
applet est envoyée au client, pour lui permettre de communiquer avec le module Hôte. Les deux
modules (Hôte et Admin) utilisent des commandes http (comme: connect, send, get) pour échanger
les mises à jour de l'écran et les évènements clavier / souris (Cf. Figure 1.2).
Figure 1.2 – Echange de données entre les module Admin et Hôte
Il y a une différence entre les deux notions client-serveur de l'ordinateur contrôlé depuis
l'ordinateur qui contrôle avec la notion habituelle de client/serveur lié au Web comme un internaute
qui navigue (client) sur un site Web (serveur), ou un client qui utilise des services fournis par un
FAI (Fournisseur d' Accès à l'Internet).
Dans la plupart des cas, c'est le client distant qui lance la connexion. L'application concernée doit
fournir les informations requises pour une connexion à l'ordinateur hôte. Vous pouvez également
sélectionner des options permettant d'améliorer la sécurité et d'optimiser les performances.
Pour établir une connexion, l'ordinateur hôte doit être configuré pour attendre les connexions
entrantes. L'utilisateur hôte peut sélectionner le type de périphérique à utiliser pour les connexions
de type TCP/IP (Transmission Control Protocol / Internet Protocol) et les options de sécurité
permettant de contrôler et de limiter l'accès à l'ordinateur hôte.
6. Mise en place
Nous discutons sur quelques problèmes qui peuvent être rencontrés et qui empêchent ou réduisent
les performances et on va voir des solutions appropries pour éliminer ou réduire l'effet produit par
ces problèmes.

8
6.1. Problématiques et solutions appropriées
Plusieurs facteurs peuvent empêcher l'établissement de la connexion entre les deux modules Admin
et Hôte, parmi aux on distingue :
6.1.1. PC derrière un pare-feu
Le pare-feu doit laisser les connexions entrantes et sortantes sur les adresses et les ports utilisés par
le bureau distant, ainsi; il ne doit pas bloquer les modules Hôte et Admin.
Si l'utilisateur ne peu pas autoriser ces modules à agir librement; et si les connexions entrantes et
sortantes sont interdites alors il est obligé d'utiliser des outils tel qu'un tunnel http s’il est autorisé.
6.1.2. PC derrière un routeur
Si un ordinateur se trouve dans un réseau local, et celui là est derrière un routeur, alors il n'est pas
accessible, la technique de la redirection des ports peut être utile pour le rendre accessible à
condition que les connexions entrantes sont autorisées; si non l’application du tunnel http peut
résoudre le problème.
6.1.3. Pas de connexions entrantes
Par mesure de sécurité; Certains FAI, routeurs et/ou pare-feux bloquent les connexions entrantes (le
trafic entrant), c'est-à-dire si un ordinateur est dans un réseau local alors il n'est pas accessible,
donc, nous ne pouvons pas le contrôler.
La solution de ce problème consiste à utiliser un relai (appelé aussi un répéteur).
6.1.4. Adresse IP dynamique
Se dit d'une adresse affectée à une machine au moment de sa connexion au réseau. Étant donné que
cette adresse n'est pas fixée d'avance et qu'elle peut donc être différente d'une session à l'autre, elle
est appelée dynamique par opposition à une adresse statique. Cette adresse est attribuée par le
fournisseur d'accès à l’Internet (FAI) lorsqu'on connecte à Internet. Elle est temporaire et sera
reprise par un autre utilisateur après votre déconnexion. D'où la difficulté particulière d'appeler un
poste précis en téléphonie sur Internet. Comme solution de ce problème certains FAI proposent en
option une adresse statique. Une autre solution, c'est le service d'adressage dynamique. (voir la
technique : DNS Dynamique).
6.2. Techniques d'aide pour accès à distance
Dans cette partie, on va présenter quelques techniques qui peuvent être utiles, pour faciliter la tâche
à l'utilisateur afin d'accéder à son ordinateur quelque soit sa situation et son emplacement.
6.2.1. DNS dynamique
Ce service permet à quelqu'un n'ayant pas d'adresse IP (Internet Protocol) fixe d'avoir une entrée
DNS (Domain Name Server) afin de pouvoir lancer un serveur Web par exemple. La façon de faire
la plus courante est d'avoir un client qui mémorise votre adresse IP à des intervalles spécifiques et
qui vérifie si elle correspond à la base de données DNS du serveur que vous utilisez. Sinon, il met à
jour cette base tout simplement.

9
No-IP.com à mis un service gratuit (Free Dynamic DNS) qui permet d'associé un nom d'hôte (par
exemple jrdesktop.no-ip.org) avec une adresse IP de la machine (par exemple 41.221.16.145), un
logiciel appelé No-IP DUC (Dynamic Update Client) est fourni gratuitement (sous Windows, Unix
et Mac) est utilisé pour faire la vérification et la mise à jour de l'adresse IP chaque fois que la
machine est connectée à l'Internet, l'utilisateur peut bénéficier à tout moment de ce nom d'hôte pour
accéder à sa machine.
6.2.2. Redirection des ports
Cette technique est fournie avec la plupart des routeurs, elle consiste à rediriger des paquets
réseaux reçus sur un port donné d'un ordinateur (ou d'un équipement réseau) vers un autre
ordinateur (ou équipement réseau) sur un port donné. Cela permet entre autre de proposer à des
ordinateurs extérieurs à un réseau d'accéder à des services répartis sur plusieurs ordinateurs de ce
réseau.
PortForward.com fournit des guides détaillés concernant la configuration des routeurs pour
l'utilisation de la redirection des ports.
A l'aide de cette technique, on peut par exemple accéder à notre machine par la redirection du port
3389 (par défaut) de "Connexion Bureau à Distance" de Windows. Même chose avec le port 5900
(par défaut) de RealVNC.
La redirection des ports peut être utilisée avec une extension d'UltraVNC appelé Repeater pour
accéder à plusieurs hôtes en utilisant un seul port.
Le routeur est configuré pour rediriger des paquets reçus sur le port 5901 vers l'adresse IP
10.10.10.11, ce dernier est équipé d'un répéteur (Repeater) et d'un serveur VNC (Cf. Figure 1.3).
Figure 1.3 – Accès à plusieurs serveurs VNC à l’aide d’un seul port
Le visualisateur (VNC Viewer) peut accéder à tous les PCs d’un réseau distant qui sont équipés
d'un serveur VNC (VNC Server), il suffit d'indiquer (dans la boite de dialogue de la connexion de

10
Viewer) l'adresse IP du réseau avec le port de redirection comme un répéteur
(41.200.207.242:5901), et l'adresse du PC (Personal Computer) avec le port (par défaut) comme un
serveur VNC (10.10.10.12:5902).
6.2.3. Relai (ou répéteur)
Si les connexions entrantes sont interdites, alors la solution c’est d’utiliser un programme (un
serveur) appelé "relai" qui agit comme une passerelle entre les deux modules. Ces deux derniers
deviennent des clients communiquant avec ce serveur (le relai). Le rôle de ce relai est d’échanger
les paquets entre les clients connectés (Cf. Figure 1.4).
Figure 1.4 - Relai établit des connexions entre visualisateurs et serveurs VNC
Le relai utilise une base de données pour stocker des informations concernant les serveurs VNC
connectés, en introduisant l'identifiant et le mot de passe d'un serveur VNC, un visualisateur peut se
connecter à ce dernier sans savoir son adresse IP.
La solution EchoVNC propose un module intégré appelé echoWare (Cf. Figure 1.5), ce module
permet à toutes les applications point à point ou client/serveur: bureau distant, VoIP (Voice Over
IP), chat vidéo, …etc, d'utiliser un relai afin de réaliser une, chat vidéo, …etc.) d'utiliser un relai
afin de réaliser une connection sécurisée de bout en bout sans adaptation aux pare-feux, proxy ou
aux routeurs NAT. Via echoWare toutes les connexions apparaissent au réseau comme des
connexions sortantes vers le même port TCP du echoServer.

11
Figure 1.5 - Diverses fonctionnalités d'echoServer
6.2.4. Tunnel http
C’est une technique par la quelle les communications s'effectuent à l'aide des différents protocoles
TCP/IP encapsulés sous le protocole http qui joue le rôle de couverture d'un canal de
communication caché derrière un tunnel. Le canal caché avec le flux de données est appelé tunnel
http.
Cette technique est établit par un logiciel client/serveur qui gère la communication (Cf. Figure 1.6).
Figure 1.6 - Communication à l'aide d'un tunnel http
7. L'utilisation du bureau distant
Le bureau distant peut servir à plusieurs utilisations, on cite les suivantes :
· Maintenance, Téléintervention, réparation et aide ;
· Administration des serveurs ;
· Télétravail ;
· Assistance à distance ;
· Formation à distance ;
· Transfère des fichiers entre ordinateurs.

12
8. Comparer des différents logiciels de bureau à distance
Il existe déjà plusieurs logiciels de gestion à distance d'ordinateur disponible sur le marché. Par
ailleurs, les dernières versions des systèmes d'exploitation incluent désormais l’application à
distance et des outils d'aide et d'assistance à distance tel que Win XP.
Voici un tableau comparatif (Cf. Tableau 1.1) de quelques populaires solutions d'accès et de
contrôle à distance

13
:disponible×:nondisponible
Tableau1.1–Comparaisondesdiversesapplicationsdebureaudistant[4]

CHAPITRE II Outils et technologies utilisés
16
D'après le tableau précédant, on déduire que le logiciel le plus performant est celui qui fonctionne sur
plusieurs plateformes et qui offre plusieurs fonctionnalités: le cryptage, transfert de fichiers, sessions
multiples…etc. alors c'est le Sun Secure Global Desktop Software (SGD) qui utilise le protocole
AIP et qui fonctionne sur Microsoft Windows, Mac OS et Linux. Ainsi le Symantec PcAnywhere et
le Citrix Presentation Server qui est un produit de la société Citrix systems basé sur le protocole
Independent Computing Architecture (ICA), il est considéré comme un concurrent de SGD. Puis il y
a le Remote Desktop Connection de Microsoft qui utilise le protocole RDP, et RealVNC
Enterprise qui se servir de protocole VNC.
9. Inconvénients du bureau distant
Lorsqu'on utilise le Bureau distant on est confronté à des inconvénients qui sont :
1. L’uni-plateforme :
Cet inconvénient n’est pas pour toutes les applications de bureau distant, l’uni-plateforme l’opposé
de multiplateforme, signifie que l’application ne fonctionne que sur un seul système d’exploitation
comme Apple Remote Desktop qui marche uniquement sur Mac OS, par contre Real VNC
Enterprise n’a pas cet inconvénient.
2. Occupation de la bande passante :
Cet inconvénient dépend de la compression de données que le bureau distant l’utilise, notamment
au niveau de visualisation de l’écran de contrôlé. S’il n y a pas de compression des images envoyés
par le Hôte ou parfois même s’il y a une compression mais qu’elle n’est pas parfaitement
optimisée, ainsi, si l’utilisation des couleurs n’est pas réduite (ex. couleurs 24-bits) alors
l’occupation de la bande passante sera élevée particulièrement dans un réseau WAN, ce qui influe
sur la performance du bureau distant (rendre moins rapide que prévue).
10. Administration et contrôle par mobile
L'administration par mobile a récemment commencé à apparaître sur les appareils sans fil tels que
le BlackBerry, Pocket PC et Palm, ainsi que certains téléphones mobiles.
En général, ces solutions n'offrent pas le plein accès à distance comme VNC ou TerminalServices,
mais ne permettent pas aux administrateurs d'effectuer une variété de tâches, tel que le redémarrage
des ordinateurs, la réinitialisation des mots de passe, et l'affichage des journaux d'événements
système, ce qui réduit, voir même supprimer la nécessité pour les administrateurs système à avoir
un ordinateur portable ou de se trouver à la portée de son bureau.
RDM + (Remote Desktop for Mobiles) est un exemple de ces logiciels qui vous permet d'avoir
accès à votre poste de travail ou de votre ordinateur portable à partir d'un téléphone mobile utilisant
Java.

17
Vous pouvez ainsi envoyer et recevoir
des emails, surfer sur le web, éditer des
documents sous Word, gérer des
fichiers et des dossiers (Cf. Figure 1.7).
Le contrôle à distance par mobile, à
récemment vu la lumière à l'aide de la
technologie Bluetooth, plusieurs
applications disponibles permettant de
contrôler entièrement la machine, ou
quelques applications spécifiques, par
exemple, à l'aide du mobile, on peut
montrer une présentation, contrôler un
lecteur multimédia, verrouiller
l'ordinateur, …etc. (Cf. Tableau 1.2)
Figure 1.7 – Administration par mobile
à l'aide de RDM +
Nom du logiciel Lien Licence TCP/IP Bluetooth
RDM+ (Remote
Desktop for
Mobiles)
http://www.rdmplus.com/ Propriétaire ü ×
MRC (Mobile
Remote Control)
https://mobile-remote-control.dev.java.net/
OSS (Open
Source
Software)
ü ×
Mobile Desktop http://sourceforge.net/projects/mobiledesktop/ OSS ü ü
Rove Mobile
Desktop
http://www.rovemobile.com/products/
remoteaccess/mdt/features/
Propriétaire
ü ×
Amora
(A mobile remote
assistant)
http://code.google.com/p/amora/ OSS × ü
Bluetooth Remote
Control
http://www.bluetoothshareware.com/
bluetooth_remote_control.asp
Propriétaire × ü
anyRemote http://anyremote.sourceforge.net/ OSS ü ü
PuppetMaster http://www.lim.com.au/PuppetMaster Propriétaire ü ü
Tableau 1.2 – Quelques applications de contrôle à distance par mobile
11. Conclusion
D'une manière générale, de plus en plus d'entreprises et des particuliers utilisent le bureau distant
pour la maintenance de leurs parcs informatiques. De plus, beaucoup d'éditeurs développement des
logiciels qui répondent au maximum aux besoins des entreprises et des administrateurs systèmes.

18
Chapitre II
Outils et technologies utilisés
« Chaque mot est un préjugé »
Friedrich Nietzsche.
1. Introduction
Dans ce chapitre, on va présenter le langage Java qu'on a utilisé pour le développement de notre
application de bureau distant à l'aide du l’éditeur NetBeans.
Ainsi, on va montrer un mécanisme permettant l’appel des méthodes entre objets distribués
développés par Sun Microsystems, ce protocole est connu sous l’acronyme RMI (Remote Method
Invocation).
Par la suite, on va présenter comment sécuriser la communication à l’aide du protocole SSL. On
montre ensuite que l’éditeur NetBeans est assez puissant et qui a de grande importance.
2. Le langage Java
Le langage Java permet d'exprimer des concepts, il deviendra un moyen d'expression
considérablement plus simple et plus souple que n'importe quelle alternative, alors même que les
problèmes augmentent en taille et en complexité. C’est un langage à objets qui permet d’écrire de
façon simple et claire des programmes portables sur la majorité des plates-formes. Lié à l’essor du
World Wide Web. Il a été conçu par l’équipe de James Gosling en fonction des multiples exigences
des développements informatiques actuels [5].
2.1. Les avantages de Java
Le primordial avantage de ce langage de programmation réside dans le fait que la syntaxe de java est
analogue à celle de C++, ce qui le rend économique et professionnel. Java est un langage "à objets",
tous les éléments de Java, à l'exception de quelques types de base tels que les nombres, sont des
objets. La conception orientée objet présente de nombreux avantages pour les projets sophistiqués,
elle a remplacé les techniques structurées antérieures. On distingue ces 4 principaux avantages [6] :

19
1. La mémoire dans Java est être allouée et libérée automatiquement. Vous ne risquez pas de pertes
de mémoire.
2. Ils ont éliminé l'arithmétique des pointeurs introduisant du même coup une vraie gestion de
tableau. La notion de référence sur une zone mémoire remplace avantageusement celle de "
pointeur", car elle supprime la possibilité d'écraser toute zone mémoire à cause d'un compteur
erroné.
3. Ils ont éliminé toute possibilité de confusion entre une affectation et un test d'égalité dans une
instruction conditionnelle. L'instruction if (n = 3) ne pourra pas franchir l'étape de la compilation.
4. Ils ont supprimé l'héritage multiple en le remplaçant par une nouvelle notion d'interface dérivée
d'Objective C. Les interfaces vous offrent tout ce que vous pouvez obtenir à partir de l'héritage
multiple, sans la complexité de la gestion de hiérarchie d'héritage multiple.
2.2. Java Standard Edition 6
C'est été le lundi de 11 décembre 2006 quand Sun a officiellement publié la version 6 de Java
Platform standard Edition (Java SE) en mettant en avant les améliorations de performances de sa
dernière JVM (Java Virtual Machine) ainsi que les progrès effectués en termes de supervision et de
support des langages de scripting tiers.
3. La technologie RMI (Remote Method Invocation)
Remote method invocation. Invocation ou plus simplement « appel » de méthode distante, plus connu
sous l'acronyme RMI est une API (Application Programming Interface) Java développée par e par
Sun à partir du JDK 1.1 (Java Development Kit 1.1) permettant de manipuler des objets distants
(objet qui existe dans un autre espace adresse soit dans la même machine soit dans une machine
différente) de manière transparente pour l'utilisateur, c'est-à-dire de la même façon que si l'objet était
sur la machine virtuelle. L'utilisation de cette API nécessite l'emploi d'un registre RMI sur la machine
distante hébergeant ces objets que l'on désire appeler au niveau duquel ils ont été enregistrés.
RMI facilite le développement des applications distribuées en masquant au développeur la
communication client / serveur. La machine sur laquelle s'exécute la méthode distante est appelée
serveur. L'appel coté client consiste à obtenir une référence sur l'objet distant puis simplement
appeler la méthode à partir de cette référence.
3.1. Applications distribuées
Une application distribuée est une application dont les classes sont réparties sur plusieurs machines
différentes. Dans de telles applications, on peut invoquer des méthodes à distance. Il est alors
possible d'utiliser les méthodes d'un objet qui n'est pas situé sur la machine locale.
"Déjà dans le langage C, il était possible de faire de l'invocation à distance en utilisant RPC (Remote
Procedure Calls). RPC étant orienté "structure de données", il ne suit pas le modèle "orienté objet ".
RMI va plus loin que RPC puisqu'il permet non seulement l'envoi des données d'un objet, mais aussi
de ses méthodes. Cela se fait en partie grâce à la sérialisation des objets. Il est également possible de
charger le byte-code des classes dynamiquement. "[7].

20
3.2. Objectifs de RMI
Le but de RMI est de créer un modèle objet distribué Java qui s'intègre naturellement au langage Java
et au modèle objet local. Ce système étend la sécurité et la robustesse de Java au monde applicatif
distribué. RMI permet aux développeurs de créer des applications distribuées de manières simples
puisque la syntaxe et la sémantique restent les mêmes que pour les applications habituelles. RMI
permet de:
1- Rendre transparent l’accès à des objets distribués sur un réseau:
Avec RMI, les méthodes de certains objets (appelés objets distants) peuvent être invoquées depuis
des JVM différentes (espaces d’adressages distincts) de celles où se trouvent ces objets, y compris
sur des machines différentes via le réseau. En effet, RMI assure la communication entre le serveur et
le client via TCP/IP et cela de manière transparente pour le développeur.
2- Faciliter la mise en œuvre et l’utilisation des objets distants Java:
Il utilise des mécanismes et des protocoles définis et standardisés tels que les sockets et RMP
(Remote Method Protocol). Le développeur n'a donc pas à se soucier des problèmes de niveaux
inférieurs spécifiques aux technologies réseaux.
L'architecture RMI définit la manière dont se comportent les objets, comment et quand des
exceptions peuvent se produire ? comment gérer la mémoire ? et comment les méthodes appelées
passent et reçoivent les paramètres ?
3- Préserver la sécurité (inhérent à l’environnement Java):
RMI préserve la sécurité inhérente à l’environnement Java notamment grâce à :
· la classe RMISecurityManager, elle vérifie la définition des classes et autorise seulement les
passages des arguments et des valeurs de retour des méthodes distantes et ne prend pas en
compte les signatures éventuelles des classes.
· et au DGC (Distibuted Garbage Collector).
3.3. L'Architecture RMI
En RMI la transmission de données se fait à travers un système de couches, basées sur le modèle OSI
afin de garantir une interopérabilité entre les programmes et les versions de Java. Quant aux
connexions, elles sont effectuées grâce à un protocole propriétaire JRMP (Java Remote Method
Protocol) basé sur TCP/IP sur le port 1099 par défaut [8].
A partir de Java 2 version 1.3, les communications entre client et serveur s'effectuent grâce au
protocole RMI-IIOP (Internet Inter-Orb Protocol) [9].
3.3.1. Interface
L’interface est le cœur de RMI. L’architecture RMI est basée sur un principe important : la définition
du comportement et l'exécution de ce comportement sont des concepts séparés.
RMI permet au code qui définit le comportement et au code qui implémente ce comportement de
rester séparé et de s’exécuter sur des JVM différentes. La définition d’un service distant est codée en
utilisant une interface Java. L’implémentation de ce service distant est codée dans une classe.

21
Par conséquent, la compréhension de RMI réside dans le fait que les interfaces définissent le
comportement et les classes définissent l'implémentation.
RMI supporte deux types de classe qui implémente la même interface. La première est
l'implémentation du comportement et s'exécute du côté serveur. La deuxième agit comme un proxy
pour le service distant et s'exécute sur le client.
Un programme client crée des appels de méthodes sur le proxy, RMI envoie la requête à la JVM
distante et la transfère à l'implémentation. Toutes les valeurs de retour fournies par l'implémentation
sont retournées au proxy puis au programme client [7].
3.3.2. Les différentes couches de RMI
RMI est essentiellement construit sur une abstraction en trois couches: La couche de Stubs et
Skeletons, la couche RRL (Remote Reference Layer) et la couche Transport. La Figure 2.1 ci-
dessous montre l'architecture de RMI :
Figure 2.1 – Architecture RMI
3.3.2.1. Stubs et Skeletons
Cette première couche intercepte les appels de méthodes lancées par le client à l'interface de
référence et redirige ces appels à un service RMI distant. Le stub et le skeleton, respectivement sur le
client et le serveur, assurent la conversion des communications avec l'objet distant.
3.3.2.2. RRL
Cette couche comprend comment interpréter et gérer les références faites du client vers les objets du
service distant. Elle permet l’obtention d’une référence d’objet distant à partir de la référence locale
(le stub). Elle est assurée par le package java.rmi.Naming. On appelle cette couche généralement
registre RMI car elle référence les objets. Ce service est assuré par le lancement du programme
rmiregistery.

22
3.3.2.3. Couche Transport
La couche transport est basée sur les connexions TCP/IP entre les machines. Elle fournit la
connectivité de base entre les 2 JVM, elle permet d'écouter les appels entrants ainsi que d'établir les
connexions et le transport des données sur le réseau.
De plus, cette couche fournit des stratégies pour passer les firewalls. Elle suit les connexions en
cours. Elle construit une table des objets distants disponibles. Elle écoute et répond aux invocations.
Cette couche utilise les classes Socket et SocketServer. Elle utilise aussi un protocole propriétaire
RMP (Remote Method Protocol).
En utilisant une architecture en couche, chaque couche peut être augmentée ou remplacée sans
affecter le reste du système.
Ainsi, une application client-serveur basée sur RMI met ainsi en œuvre trois composantes :
§ une application cliente implémentant le stub.
§ une application serveur implémentant le skeleton (squelette).
§ une application médiatrice (le registre RMI) servie par un processus tiers (rmiregistry).
Lorsqu'un client désire invoquer une méthode d'un objet distant, il effectue les opérations suivantes
(Cf. Figure 2.2) [8] :
1- Il localise l'objet distant grâce à un service d’annuaire (Registry), le registre de RMI ;
2- Il obtient dynamiquement une image virtuelle de l'objet distant (stub). Le stub possède exactement
la même interface que l'objet distant ;
3- Le stub transforme l'appel de la méthode distante en une suite d'octets, c'est ce que l'on appelle la
sérialisation, puis les transmet au serveur instanciant l'objet sous forme de flot de données. On dit que
le stub "marshalise" (réalise le pliage) les arguments de la méthode distante ;
4- Le Skeleton instancié sur le serveur "désérialise" les données envoyées par le stub (on dit qu'il les
"démarshalise" c.-à-d il réalise le dépliage), puis appelle la méthode en local ;
5- Le Skeleton récupère les données (les résultats) renvoyées par la méthode (type de base, objet ou
exception) puis les marshalisent ;
6- Le stub démarshalise les données provenant du Skeleton et les transmet au client (l'objet faisant
l'appel de méthode à distance).

23
Figure 2.2 – les opérations de communication
3.4. Processus de développement d’une application RMI
Les principales étapes nécessaires à la mise en place d’un service de type RMI sont [7] :
a- Définir l'interface
La première étape consiste à créer une interface distante qui décrit les méthodes que le client pourra
invoquer à distance. Pour que ces méthodes soient accessibles par le client, cette interface doit hériter
de l'interface Remote. Cette interface devra être placée sur les deux machines (serveur et client).
b- L’implémentation de l'interface
Il faut maintenant implémenter cette interface distante dans une classe. Par convention, le nom de
cette classe aura pour suffixe Impl. Notre classe doit hériter de la classe
java.rmi.server.RemoteObject ou de l’une de ses sous-classes. La plus facile d’utilisation étant
java.rmi.server.UncicastRemoteObject.
C’est dans cette classe que nous allons définir le corps des méthodes distantes que pourront utiliser
nos clients. Evidement, il est possible d’ajouter d’autres méthodes mais les clients ne pourront pas y
accéder et donc ne pourront pas les utiliser.
c- Générer les classes Stubs et Skeletons (rmic)
Lorsque notre client fera appel à une méthode distante, cet appel sera transféré au stub. Le stub est un
relais du côté client. Il devra donc être placé sur la machine cliente.
C’est le représentant local de l’objet distant. Il « marshalise » (emballe) les arguments de la méthode
distante et les envoie dans un flux de données. D’autre part, il « démarshalise » (déballe) la valeur ou
l’objet de retour de la méthode distante. Il communique avec l’objet distant par l’intermédiaire du
skeleton (Cf. Figure 2.3).
Le skeleton est lui aussi un relais mais du côté serveur. Il devra être placé sur la machine servant de
serveur. Il « démarshalise » les paramètres de la méthode distante, les transmet à l’objet local et «
marshalise » les valeurs de retours à renvoyer au client.
Les stubs et les skeletons sont donc des intermédiaires entre le client et le serveur qui gèrent le
transfert distant des données.
On utilise le compilateur rmic pour la génération des stubs et des skeletons. C’est un utilitaire fournie
avec le JDK.

24
Figure 2.3 – Invocation d’une méthode distante et renvoie de la valeur de retour
d- Lancement de registre RMI (service d’annuaire RMI)
Les clients trouvent les services distants en utilisant un service d'annuaire activé sur un hôte connu
avec un numéro de port connu. RMI peut utiliser plusieurs services d'annuaire, y compris Java
Naming and Directory Interface (JNDI). Il inclut lui-même un service simple appelé Registry
(rmiregistry).
Le registre est exécuté sur chaque machine qui héberge des objets distants (les serveurs) et accepte
les requêtes pour ces services, par défaut sur le port 1099.
Un serveur crée un service distant en créant d'abord un objet local qui implémente ce service.
Ensuite, il exporte cet objet vers RMI. Quand l'objet est exporté, RMI crée un service d'écoute qui
attend qu'un client se connecte et envoie des requêtes au service. Après l'exportation, le serveur
enregistre l'objet dans le registre de RMI sous un nom public qui devient accessible de l’extérieur.
Le client peut alors consulter le registre distant pour obtenir des références à des objets distants.
e- Lancement de l'application serveur (Server)
Notre serveur doit enregistrer auprès du registre RMI l’objet local dont les méthodes seront
disponibles à distance. Cela se fait grâce à l’utilisation de la méthode statique bind() de la classe
Naming. Cette méthode permet d’associer (enregistrer) l’objet local avec un synonyme dans le
registre. L’objet devient alors disponible par le client.
ObjetDistantImpl od = ObjetDistantImpl()
Naming.bind("serveur", od)
f- Créer le programme client (Client)
Le client peut obtenir une référence à un objet distant par l’utilisation de la méthode statique lookup()
de la classe Naming. Il peut ensuite invoquer des méthodes distantes sur cet objet. La méthode
lookup() sert au client pour interroger un registre et récupérer un objet distant. Elle prend comme
paramètre une URL qui spécifie le nom d'hôte du serveur et le nom du service désiré. Elle retourne
une référence à l’objet distant. La valeur retournée est du type Remote.
ObjetDistant od = (ObjetDistant) Naming.lookup("//172.16.X.X/serveur")

25
g- Lancement de l’application cliente
Il est maintenant possible d’exécuter l’application. Cela va nécessiter l’utilisation de trois consoles.
La première sera utilisée pour activer le registre. Pour cela, vous devez exécuter l’utilitaire
rmiregistry.
Dans une deuxième console, exécuter le serveur. Celui-ci va charger l’implémentation en mémoire,
enregistrer cette référence dans le registre et attendre une connexion cliente.
Vous pouvez enfin exécuter le client dans une troisième console.
4. Le protocole de sécurité SSL
La question du cryptage de données échangées via Internet est plus large et plus complexe qu'il n'y
apparaît. Il ne s'agit pas seulement de sélectionner un algorithme efficace, il est de plus nécessaire de
le sécuriser. Notamment le protocole de transmission des données, ou encore le système
d'identification et notamment les mots de passe.
4.1. Définition du protocole
Secure Socket Layer (SSL) est un des protocoles les plus connus de sécurisation des échanges sur
Internet, développé à l'origine par Netscape (SSL version 2 et 3). Il a été renommé en Transport
Layer Security (TLS) par l'IETF (Internet Engineering Task Force) [4].
SSL fonctionne suivant un mode client/serveur. Il fournit quatre objectifs de sécurité importants:
· l'authentification du serveur ;
· la confidentialité des données échangées (ou session chiffrée) ;
· l'intégrité des données échangées ;
· l'authentification du client avec l'utilisation d'un certificat numérique (optionnelle).
Pour toutes applications existantes (HTTP, FTP, SMTP, etc.), il peut exister une application utilisant
SSL correspondante. Par exemple, l'application HTTPS (Secured HTTP) correspond à HTTP au
dessus de SSL.
La plupart des navigateurs web gèrent parfaitement SSLv2, SSLv3 et TLS v0.1.
4.2.1. Architecture du SSL
SSL est un protocole en couches et se compose de quatre sous protocoles (Cf. Figure 2.4) :
· SSL Handshake Protocol
· SSL Change Cipher Spec Protocol
· SSL Alert Protocol
· SSL Record Layer
SSL se situe dans la couche application du modèle TCP/IP (et dans la couche session du modèle
OSI). Voici une illustration du modèle TCP/IP [10] :

26
Figure 2.4 – SSL et ces sous protocoles dans le modèle TCP/IP
4.2.2. Fonctionnement du SSL
Théoriquement SSL est simple, il négocie les algorithmes de cryptographie et les clés entre les deux
faces d'une communication (généralement client et serveur), et établit un tunnel chiffré (sécurisé)
grâce à laquelle d'autres protocoles (comme HTTP) peuvent être transportés. En option, SSL peut
également authentifier les deux parties de la communication grâce à l'utilisation des certificats [10].
Mais comment fonctionne t-il ? La Figure 2.5 diagramme ci-dessous montre (d’une façon simplifiée),
étape par étape processus de mise en place d’une nouvelle connexion SSL entre le client
(généralement un navigateur web) et le serveur (généralement un serveur web SSL).

27
Figure 2.5 – Étapes d’établissement des connections SSL
Comme vous pouvez le voir sur le schéma précèdent, le processus de création de chaque nouvelle
connexion SSL commence avec l'échange de paramètres de chiffrement et puis en option
d'authentification des serveurs (en utilisant le protocole SSL Handshake). Si la poignée de main est
couronnée de succès et les deux parties d'accord sur une série commune de chiffrement et des clés de
chiffrement, les données d'application (généralement HTTP, ou un autre protocole) peuvent être
envoyés par un tunnel de chiffrement (en utilisant le protocole SSL Record Layer). En réalité le
processus montré précédemment est très compliqué [10].

28
4.2. Java et SSL
Java implémente SSL dans un package appelé JSSE (Java Secure Socket Extension), ce package
contient des outils permettant de faire communiquer un serveur HTTPS (serveur sécurisé par SSL)
avec une application cliente en Java.
SSL (aujourd'hui en version 3.0) permet d'utiliser des sockets sécurisés en manipulant des clés
publiques pour l'authentification et des clés privées pour le cryptage. L'API JSSE fournit les classes
permettant de programmer tout ceci en Java: on les trouve dans les paquets javax.net, javax.net.ssl et
javax.security.cert dont les principales classes sont les suivantes [11] :
· SSLSocket et SSLServerSocket ;
· SocketFactory et ServerSocketFactory;
· SSLSocketFactory et SSLServerSocketFactory.
Puisque notre application utilise RMI comme un support de transmission ; les classes
correspondantes sont SslRMIClientSocketFactory et SslRMIServerSocketFactory.
SSL peut être utilisé avec RMI pour assurer :
· L’authentification du serveur et des clients (optionnelle).
· La protection d’accès au RMI Registry : refus des requêtes des clients envoient des certificats
non sécurisées.
· La confidentialité et l’intégrité des données échangées entre le client et le serveur RMI.
L'authentification est réalisée au moyen d'une paire de clés (une clé publique/une clé privée) et d'un
certificat. On peut créer ces clés avec un certificat auto-signé au moyen de keytool, un utilitaire
disponible avec JDK:
keytool -genkey keyalg RSA -alias duke -keypass dukekeypasswd
Quelques autres données peuvent être fournies en paramètre, tel que l’algorithme de cryptage (ici est
RSA), l’alias (ici est "duke") et le mot de passe (ici est "dukekeypasswd").
L’appellation de ces clés se fait par l’invocation (par notre application) des propriétés système :
javax.net.ssl.trustStore et javax.net.ssl.keyStore, et les mots de passe par des propriétés :
javax.net.ssl.trustStorePassword et javax.net.ssl.keyStorePassword.
4. NetBeans
NetBeans est IDE (Integrated Development Environment) pour Java réunissant tous les outils
nécessaires à la création d'applications, aussi complexes qu'elles soient. NetBeans est un
environnement multi plate-forme développé et placé en open source par Sun Microsystems en juin
2000 sous licence CDDL (Common Development and Distribution License). En plus de Java,
NetBeans permet également de supporter différents autres langages, comme Python, C, C++, XML et
HTML. Il comprend toutes les caractéristiques d'un IDE moderne (éditeur en couleur, projets multi-
langage, refactoring, éditeur graphique d'interfaces et de pages web).
Conçu en Java, NetBeans est multilingue disponible sous Windows, Linux, Solaris (sur x86 et
SPARC), Mac OS X et OpenVMS.

29
La licence de NetBeans permet de l'utiliser gratuitement à des fins commerciales ou non. Elle permet
de développer tous types d'applications basées sur la plateforme NetBeans. Les modules que vous
pourriez écrire peuvent être open-source comme ils peuvent être closed-source, Ils peuvent être
gratuits, comme ils peuvent être payants [12].
La version 6.0 inclut des améliorations importantes et de nouvelles fonctionnalités, notamment un
éditeur complètement réécrit l'infrastructure, le soutien à d'autres langues, de nouvelles
fonctionnalités de productivité, et un processus d'installation simplifié qui vous permet d'installer et
de configurer l'IDE pour répondre à vos besoins précis (Cf. Figure 2.6).
Figure 2.6 – Interface de L’IDE NetBeans 6.0
Pour autant, il y a aussi beaucoup de nouveautés. En particulier l'éditeur de code a été complètement
réécrit pour permettre de meilleurs refactorisation, le support de nombreux langages au delà de Java
et une utilisation d'écritures imbriqués (JavaScript dans JSP, Java dans PHP, ...). Il y a aussi le
support de nouveaux langages et en particulier pour Ruby et/ou JRuby on Rails. JavaScript, PHP,
Groovy et d'autres ne sont pas loin derrière [13].
5. Conclusion
Le choix d’un langage de développement, un environnement de tests et des
technologies indispensables en général semblent très primordial pour développer une
application d'un bureau distant. L’utilisation de Java représente un intérêt parfait
notamment la portabilité, la robustesse et le multithreading qu’il offre et qui inclue
comme package RMI. Ce dernier est simple à mettre en œuvre dont un objet
distribué se manipule comme tout autre objet Java. SSL en tant que protocole de cryptage
peut être utilisé avec RMI pour assurer une sécurisation d’échange de données et d’authentification.
L'éditeur NetBeans présente un avantage grâce aux fonctionnalités intéressantes qu’il offre.

CHAPITRE III Modélisation et Architecture
28
Chapitre III
Modélisation et Architecture
« Qui veut construire d’abord étudie le terrain, puis fait un tracé du projet. »
William Shakespeare.
1. Introduction
La production et la maintenance de composants logiciels de qualité est faisable et aisé en suivant des
méthodologies adaptées au ingénierie logicielle, tel que le génie logiciel, qui est définie comme un
"ensemble des connaissances, des procédés et des acquis scientifiques et techniques mis en
application pour la conception, le développement, la vérification et la documentation de logiciels,
dans le but d'en optimaliser la production, le support et la qualité." [14]
La modélisation par objets est une technique permet d'obtenir une représentation abstraite du
système. L'approche objet consiste à représenter le système en un ensemble d'entités. L'entité
regroupe des caractéristiques principales (par exemple taille, couleur ….etc.) et des opérations sur ces
caractéristiques (par exemple changer la taille, mélanger les couleurs…etc.).
La démarche suivie dans notre projet est la suivante :
§ Collection, étude et sélection des besoins d'utilisation et des fonctions distinctives offertes par
divers logiciels de bureau à distance existants (listés dans le tableau 1.1).
§ Consultation des cours et des tutoriaux et de la documentation API du Java [15].
§ Exploration du code source des projets open source de bureau à distance développés en Java
(listés dans les tableaux 4.7 et 4.8) pour savoir comment les besoins sont-ils répondus.
§ Essais des différents algorithmes et des techniques (communication par RMI, cryptage,
compression de données, conversion de couleurs…etc.) disponibles sur le net.
§ Développement incrémental de l'application et effectuation des tests en parallèle.
§ En cas de problèmes ; consultation et participation aux divers forums de discussion [16].
§ Hébergement et suivi du notre application sur le net.

29
2. Modélisation
Dans ce qui suit, on va présenter le diagramme de cas d'utilisation, de classe, de composants et le
diagramme de déploiement de notre application.
2.1. Diagramme de cas d'utilisation
Les cas d'utilisation (en anglais use cases) permettent de représenter le fonctionnement du système
vis-à-vis de l'utilisateur, c'est donc une vue du système dans son environnement extérieur [9].
Le diagramme suivant montre les principaux cas d'utilisation du système developpé (Cf. Figure 3.1):
Figure 3.1 - Diagramme de cas d'utilisation
2.2. Diagramme de classe
Le diagramme de classe est le point central dans un développement orienté objet. En analyse, il a
pour objectif de décrire la structure des entités manipulées par les utilisateurs, et en conception,
le diagramme de classes représente la structure du code source.

30
Voici un diagramme de classe simplifiée du système (Cf. Figure 3.2):
Figure 3.2 - Diagramme de classe
L'annexe B présente la description détaillée de toutes les classes du notre application jrdesktop.
2.3. Diagramme de composant
Ce diagramme (Cf. Figure 3.3) décrit l'architecture physique de l'application, en terme de modules:
fichiers source, librairies, exécutable…etc [17].
La relation d'utilisation (uses) peut être une des opérations suivantes: lecture, écriture ou mise à jour
sur le fichier. Tous les fichiers utilisés sont de type data (données) dont :
§ config: fichier de la configuration du l'application.
§ server.config: fichier de la configuration du serveur.
§ viewer.config: fichier de la configuration du visualisateur.
§ keystore et truststore: clés de sécurité (requérable par le protocole SSL).
Figure 3.3 - Diagramme de composants

31
L'application (sous forme d'un paquetage) est composée de 2 sous systèmes Viewer et Server. Les
composants (sous forme d'un fichier de données) sont soit propre au système tout entier, soit relié à
un sous système spécifique.
Les fichiers de configuration seront crées de nouveau à leurs première utilisation, si l'utilisateur
supprime un de ces fichiers, ils sont récrées dans leur prochaine appels (avec des paramètres par
défaut).
Les clés de sécurité sont nécessaires pour les communications sécurisées avec SSL, si elles sont
supprimées, elles seront automatiquement extraites du fichier archive jrdesktop.jar
2.4. Diagramme de déploiement
Le diagramme de déploiement montre la disposition physique des matériels qui composent le
système, et la répartition des composants sur ces systèmes [17].
Le diagramme (Cf. Figure 3.4) est constitué de deux nœuds matériels de même type (un ordinateur de
bureau).
JRE (Java Runtime Execution) ou simplement la mémoire virtuelle (JVM) représente l'enivrement
d'exécution du notre application qui est implémenté à chaque machine.
A Chaque JVM; une instance de jrdesktop est en exécution, l'une des instances représente le
visualisateur et l'autre le serveur jrdesktop. Le visualisateur dispose d'une interface client pour
faciliter à l'utilisateur l'observation et/ou le contrôle. Ainsi, Plusieurs visulisateurs peuvent connectés
à un server jrdesktop.
TCP/IP représente le support de communication qui relie les visualisateurs avec le serveur distant.
Figure 3.4 - Diagramme de déploiement

32
3. Architecture de l'application
Dans ce qui suit, on va présenter l'architecture générale et le fonctionnement de notre application
jrdesktop.
Au moins deux modules de base (Admin et Hôte) sont nécessaires pour établir le bureau distant. Ces
modules sont liés par un réseau TCP/TP (LAN, MAN ou WAN).
Tandis que le module Hôte fait à touts moment des impressions de son écran; la fenêtre principale du
module Admin enregistre la trace de tous les événements clavier et souris générés par l'utilisateur du
système.
D'une façon simplifiée, deux flots de données passent entre les deux modules d'une manière
permanente grâce à l'exécution des boucles infinies utilisées par des threads implémentés aux
modules, ces flots sont: le transfert des événements clavier et souris vers l'Hôte vis-à-vis la
récupération des captures d'écran par l'Admin (Cf. Figure 3.5).
Figure 3.5 – Schéma général d'une application de bureau distant
3.1. Architecture générale
Puisque jrdesktop est entièrement développé en Java; il hérite alors tous les avantages du Java, tel
que la portabilité. jrdesktop peut être exécuté dans n'importe quelle plateforme où Java est installé.
jrdesktop est une application portable qui n'a pas besoin d'un module d'installation. Le visualisateurs
et le server sont regroupés en une seule application dans un seul fichier exécutable. Tous les fichiers
nécessaires au fonctionnement de l'application (fichiers binaires, images, fichiers de configuration et
de sécurité) sont stockés dans le fichier archive (porte l'extension .jar) de l'application qui a une taille
inférieur à 300 KB.
La structure de l'application est hiérarchique; elle est composée d'un ensemble de sous-paquetages
imbriqués; chaque paquetage peut contenir un ensemble de classes. Les paquetages sont les suivants:
+ jrdesktop: paquetage principal;
+ jrdesktop.viewer: paquetage visualisateur;
+ jrdesktop.viewer.main: paquetage principal du visualisateur;
- jrdesktop.viewer.FileMng: paquetage de la gestion de fichiers;
- jrdesktop.viewer.rmi: paquetage RMI du visualisateur;
+ jrdesktop.server: paquetage serveur;
- jrdesktop.server.main: paquetage principal du serveur;
- jrdesktop.server.rmi: paquetage RMI du serveur;
- jrdesktop.utilities: paquetage utilitaire;
- jrdesktop.images: paquetage d'images.

33
Parce que l'application est distribuée, et utilise la technologie RMI pour la communication; elle est
divisée en deux modules – de base - Viewer et Server. Les paquetages jrdesktop, utilities et images
sont partagés entre les deux modules, de plus, chaque module à ses propres paquetages: main et rmi.
Voici les différentes associations utilisées dans le diagramme de paquetage (tableau 3.1):
DescriptionAssociation
Association à navigabilité restreinte
(association directionnel)
le serveur est le propriétaire du robot
Association bidirectionnelle
Relation de réutilisation
ServerInterface est une classe réutilisable
(représente le comportement visible du ServerImpl)
Relation d'inclusion
ImageSelection est incluse dans ClibprdUtility
Tableau 3.1 - Diverses associations
Le schéma suivant (Cf. Figure 3.6) présente le diagramme de paquetage du jrdesktop, le diagramme
est automatiquement généré par l'outil Reverse Engineering qui permet d'obtenir les différents
diagrammes UML à partir d'un code source écrit par un langage objet (tel que Java et C++).

34
Figure 3.6 - Diagramme de paquetage
3.2. Architecture RMI
La communication entre les modules se fait par l'invocation de méthodes distantes en utilisant RMI
(Remote Method Invocation). Les modules (serveur et visualisateur) représentent des objets distants
communiquent entre eux (d'une façon transparente par l'utilisateur). RMI facilite l'échange des
messages entre objets distribués.
L'application du jrdesktop est constituée de deux sous systèmes (Viewer et Server). Chaque module
est constitué d'un ensemble de sous modules communiquant par messages entre eux.
Le visualisateur et à travers un objet instancié du classe ServerInterface fait appel à des méthodes
distants du ServerImpl (implémenté du ServerInterface). A son tour; ServerImpl exécute les
méthodes serveurs et renvoie optionnellement des valeurs.
Le schéma suivant (Cf. Figure 3.7) présente les couches RMI et la correspondance avec le modèle
TCP/IP

35
Figure 3.7 – Architecture RMI du jrdesktop
Tandis que les classes stub et le skeleton (générés par l'utilitaire rmic du JDK) assurent la conversion
des communications avec l'objet distant; Le registre RMI (ou bien la couche RRL) traduit et gère les
références vers les objets distant.
3.3. Communication entre modules
Avant d'étudier l'architecture des modules du jrdesktop, on s'intéresse sur la nature des données
échangées entre les modules.
La communication entre le visualisateur et le serveur est gérée par le protocole JRMP (Java Remote
Method Protocol). Le passage de données est par défaut non sécurisé. Le protocole SSL peut être
utilisé en conjonction avec JRMP pour établir une connexion sécurisée entre les deux modules.
Les flux de données échangés entre modules sont :
§ Authentification : demande de la connexion ou de la déconnexion d'un visualisateur à un
serveur jrdesktop. Si l'opération a échouée, une erreur est signalée. Ce flux peut contenir
plusieurs informations tel que : l'adresse IP et le port du serveur, le nom et le mot de passe
d'utilisateur et le type de connexion (sécurisée ou non).
§ Transfert des entrées-sorties: passage des événements clavier et souris (comme entrées) et
des imprimes d'écran (sorties). Ce transfert s'effectue d'une manière permanente.
§ Transfert des paramètres: transférer des options sélectionnées du visualisateur vers le
serveur pour être appliqués dans le transfert de données, tel que: l'activation de la
compression, le passage du contenu du presse-papiers…etc.
§ Transfert de fichiers: opération de la copie des fichiers (de petites tailles) listés dans le
presse-papiers d'un PC vers la mémoire de stockage de l'autre PC, ou par un glissement des
fichiers sur la fenêtre de la visualisation pour les transmettre au serveur.
Sauf dans le cas d'envoi des paramètres; le passage de tous les flux est bidirectionnel. Ainsi, tous ces
flux passent d'une façon facultative et seulement à la demande, excepte celui d'entrées-sorties.

36
Voici un schéma (Cf. Figure 3.8) présente les types de flux de données échangés entre le
visualisateur et le serveur.
Figure 3.8 - Flux de données échangés entre modules
Ces flux sont établis par appel de méthodes distantes depuis le visualisateur, et - optionnellement - la
récupération du résultat des méthodes appelées. Les méthodes sont les suivantes:
§ startViewer et stopViewer pour l'authentification ;
§ updateData : pour le transfert d'entrées-sorties ;
§ updateOptions : pour l'envoi des paramètres ;
§ sendFile et receiveFile : pour la transmission des fichiers.
3.4. Architecture des modules
Après avoir vu comment les données sont transférées entre modules, on s'intéresse maintenant à
l'architecture interne de chaque module.
Chaque module dispose d'un ensemble d'outils pour prendre le contrôle des ressources tel que:
clavier, souris, écran, presse-papiers et un ensemble de structures (objets, listes, tableaux…etc.).
Dans ce qui suit, on essaye d'expliquer le rôle et le fonctionnement de chaque outil et structure.
Les outils de contrôle de clavier, souris et écran sont partagées à tous les visualisateurs, les structures
sont particulières, chaque visualisateur dispose ses propres structures. Les structures particulières
(dans les deux modules) sont crées juste après l'authentification et détruites lorsque la session est
terminée.
a. Module Viewer (Admin) :
Ce module (Cf. Figure 3.9) est responsable de la visualisation, à travers une interface utilisateur
(GUI); l'utilisateur peut facilement observer ou contrôler l'ordinateur distant. Plusieurs
fonctionnalités sont à leur disposition, tel que la possibilité de suspendre et de reprendre la
visualisation, changer la taille et le zoom d'écran, régler le niveau de la compression et choisir la
palette de couleurs souhaitable….etc.
Le module est construit d'un ensemble de paquetages, classes, fenêtres, objets…etc.

37
Figure 3.9 – L'architecture interne du module Viewer
Dans ce qui suit on va voir les principaux sous composants du module qu’on a appelé « Viewer » qui
désigne le visualisateur ou le contrôleur.
§ (1) : La classe principale est « Viewer », cette classe est responsable de la communication avec le
serveur. Lorsque on veut envoyer ou recevoir une donnée, le visualisateur cherche dans le registre
RMI l'objet désiré, lorsque sa référence est récupérée, la méthode distante est invoquée (et
optionnellement, cette méthode renvoie une valeur en retour).
§ (2) : La configuration de la connexion de ce module est gérée par une classe spéciale surnommée
« Config » où on trouve un ensemble de paramètres configurables tel que: l'adresse IP et le port
du serveur, le nom et le mot de passe d'utilisateur et l'activation (ou non) de la sécurité. L'intérêt
de cette classe est d'éviter l'insertion des paramètres à chaque nouvelle session, car ils sont
récupérés du fichier de la configuration qui est situé sur le disque dur.
§ (3) : « Recorder » est une classe (sorte de processeur) qui gère le module tout entier, on trouve à
cette classe la définition de l'ensemble des ressources, la boucle permanente qui est responsable
d'émission et de réception des données et les opérations de lancement et d'arrêt du système.
§ (4) : L'interface utilisateur « ViewerGUI » permet au visualisateur de contrôler la visualisation
toute entière. C'est une fenêtre où il y a des boutons, cases à cochés, listes déroulantes...etc.
§ (5) : « ScreenPlayer » est un sous composant de GUI (de type JPanel) où on observe et on
contrôle l'ordinateur distant par l'affichage des captures d'écran reçues, la récupération et puis
l'envoi de la position du curseur et touches appuyées.
§ (6) : Le presse-papiers (clipboard en anglais) est administré par une classe utilitaire nommée
« ClipbrdUtility », son rôle est l'observation du contenu, et la récupération de ce contenu à la
demande. Le contenu peut être des textes, images ou listes de fichiers et/ou des dossiers.

38
§ (7) : Les statistiques sont gérées par la classe « ConnectionInfo », à chaque transfert de données,
la classe est appelée pour faire une mise à jour des données suivantes: la durée de transmission,
taille des données émises et reçues et vitesse de transfert.
§ (8) : « FileManager » est responsable de la communication avec la mémoire morte (disque dur)
par le placement des fichiers et/ou des dossiers reçus du serveur, ou la récupération des fichiers
et/ou des dossiers pour être transférés à l'ordinateur distant.
§ (9) : Les paramètres de la visualisation sont gérés par la classe « ViewerData », tel que le niveau
de compression, palettes des couleurs utilisées, taille de l'écran, niveau de qualité d'image
JPEG…etc. Une copie entière de ces paramètres est dans la possession du serveur pour assurer
une gestion efficace de tous les visualisateurs connectés.
Outre les présidents composants, ce module contient d'autres fenêtres de dialogue, et d'autres classes.
(La structure de chaque classe est détaillée dans l'annexe B).
La structure objet du jrdesktop donne la possibilité d'utiliser autant de visualisateurs (dans la même
machine) sans avoir une interférence entre eux.
b. Module Server (Hôte) :
Ce module (Cf. Figure 3.10) est responsable de la production des captures d'écran et d'application des
événements clavier et souris reçus par les visualisateurs. L'utilisateur peut facilement lancer, arrêter
ou bien configurer le serveur. Ainsi, le module dispose d'une interface graphique qui permet de gérer
les visualisateurs connectés.
Figure 3.10 - La structure interne du module Server
Par l'exécution de jrdesktop, une seule instance de ce module peut être crée.
Le module est construit d'un ensemble de paquetages, classes, fenêtres, objets…etc. Dans ce qui suit
on va voir les principaux sous composants de ce module.

39
§ (1): Outre la communication et la gestion des visualisateurs connectés, la classe « Server »
est responsable du lancement et d'arrêt du serveur RMI. Ainsi la construction du Registre RMI.
§ (2): « robot » est une classe hérité du Robot du Java (cette classe est originalement développée
pour la génération des tests automatisés des applications Java). robot est responsable de la
production des événements d'entrées (clavier + souris) virtuels, c'est-à-dire le déplacement du
curseur sur l'écran et la réponse aux touches appuyées par le visualisateur. L'utilisation de cette
classe est partagée avec tous les visualisateurs connectés.
§ (3): La configuration de la connexion de ce module est gérée par une classe spéciale où on trouve
un ensemble de paramètres configurables tel que: l'adresse IP local et le port par défaut, le nom
d'utilisateur et le mot de passe et l'activation (ou non) de la sécurité, l'utilisation (ou non) d'un
serveur multihome. L'intérêt de cette classe est d'éviter l'insertion des paramètres à chaque
lancement du serveur, car ils sont récupérés du fichier de la configuration qui est situé sur le
disque dur.
§ (4): La même classe utilisée dans le visualisateur (même fonctionnement).
§ (5): Les données des clients connectées sont stockées dans une liste tabulaire (de type ArrayList),
cette liste permet de traiter les besoins de chaque visualisateur séparaient, chaque entrée de cette
liste est un objet de type ViewerData (voir le composant 9 du visualisateur).
§ (6): De même, Les statistiques des visualisateurs sont gérées par la classe ConnectionsInfo (sous
forme d'une liste tabulaire). A chaque transfert de données; la classe est appelé pour faire une
mise à jour des données suivantes: la durée de la transmission, taille des données émises et reçues
et vitesse de transfert. Chaque entrée de cette liste est un objet de type ConnectionInfo (voir le
composant 7 du visualisateur).
§ (7): FileManager est responsable de la communication avec la mémoire morte (le disque dur par
exemple) par le placement des fichiers et/ou des dossiers reçus à partir du visualisateur. Ainsi, la
récupération des fichiers et/ou des dossiers pour être transférés à l'ordinateur distant.
Outre les présidents composants, le module contient d'autres fenêtres de dialogue, et d'autres classes.
(La structure de chaque classe est détaillée dans l'annexe B).
Contrairement au module Viewer; une seule instance de ce module peut être lancée dans une
exécution de l'application jrdesktop.
3.5. Fonctionnalités de base
Après avoir vu l'architecture générale du jrdesktop et la structure des modules Viewer et Server et la
manière de communication entre eux; on va présenter dans cette partie quelques aperçues du code
source on inspirant à faciliter la tache aux lecteurs de comprendre le fonctionnement de l'application.
3.5.1. Transfert de données
Dans cette partie, on va présenter la nature des données transférées entre les modules, le transfert ce
fait par appel des méthodes distants par le visualisateur, et la réception optionnelle des valeurs en
retour.

40
a. Processus d'authentification
Une fenêtre de connexion permet à l'utilisateur de se connecter à un serveur distant, en donnant
l'adresse local et le port – par défaut -, le nom et le mot de passe d'utilisateur comme paramètres.
rmiServer = (ServerInterface) registry.lookup("ServerImpl");
index = rmiServer.startViewer(InetAdrUtility.getLocalAdr(), username, password);
if (index == -1) {
JOptionPane.showMessageDialog(null, "Wrong username or password !!", "Error",
JOptionPane.ERROR_MESSAGE);
return -1;
}
Après la connexion au registre RMI et la récupération de l'objet distant (rmiserver); la méthode
startViewer permet de vérifier si le nom et le mot de passe sont justes ou non; la méthode renvoie la
valeur -1 si l'authentification a échouée.
b. Transfert des entrées-sorties
Au début, la session d'enregistrement est en attente. Au lancement de la visualisation; la session sera
notifiée et la variable pause est initialiser à faux, deux méthodes sont appelées d'une manière infinie:
l'émission et la réception des données. Le processus de transfert de données est le plus important et
aussi le plus compliqué. En résumé, il est comme suite (Cf. Figure 3.11):
Figure 3.11 – Organigramme du transfert de données
Envoie des données
Le visualisateur utilise une collection d'objets; cette collection contient des :
o Evénements souris : déplacement, glissement, défilements, boutons enfoncés et relâchés;
o Evénements clavier: touches enfoncées et relâchées;
o Liste des fichiers à envoyé si elle existe;
o Contenu du presse-papiers s'il est actif et si son contenu est changé;
o Propriétés de l'ordinateur local s'ils sont demandées.

41
Si la compression est activé; la collection est alors compressée. Par la suite; la collection est convertie
en un tableau d'octets et elle est ensuite envoyée;
De son tour; le serveur renvoie ce tableau d'octets, si la compression est activé; ce tableau est alors
décompressé; les événements clavier et souris sont appliqués; si une liste de fichiers est reçue,
le transfert des fichiers est commencé, le contenu du presse-papiers est modifié et les propriétés de
l'ordinateur distant sont enregistrées.
Réception des données
Le serveur lui-même utilise une collection d'objets; cette collection contient:
§ Dimension d'écran;
§ Capture d'écran;
§ Liste des fichiers à envoyé si elle existe;
§ Contenu du presse-papiers s'il est actif et si son contenu est changé;
§ Propriétés du serveur s'ils sont demandées.
Si la compression est activée; la collection est alors compressée. Par la suite; la collection est
convertie en un tableau d'octets et elle est ensuite envoyée;
De son tour; le visualisateur reçoit ce tableau d'octet; il est décompressé si la compression est activée,
la nouvelle dimension d'écran est appliquée si elle est différente de l'ancienne; l'écran est actualisée,
si une liste de fichiers est reçue, le transfert des fichiers est commencé, le contenu du presse-papiers
est modifié et les propriétés du serveur sont affichées à l'écran.
c. Transfert des paramètres
Pour assurer une bonne performance; les paramètres de visualisation sont partagés et synchronisés
entre le visualisateur et le serveur; à chaque changement d'un paramètre (par exemple activation de la
compression, changement du niveau de la qualité d'image JPEG, sélection d'une nouvelle palette de
couleurs…etc.) le paramètre est immédiatement envoyé au serveur, et l'option est alors appliquée à
partir du prochain transfert de données.
d. Transfert de fichiers
A la réception d'une liste de fichiers (par le visualisateur ou le serveur); le gestionnaire de fichiers
commence l'opération de transfert en utilisant des méthodes d'envoi et de réception implémentées aux
deux modules. A titre d'exemple; voici les méthodes de transfert de fichiers côte serveur:
§ Pour la réception d'un fichier:
public static byte[] ReceiveFile(String fileName){
try {
File file = new File(fileName);
byte buffer[] = new byte[(int)file.length()];
BufferedInputStream input = new
BufferedInputStream(new FileInputStream(file));
input.read(buffer, 0, buffer.length);
input.close();
return(buffer);
} catch(Exception e){
e.printStackTrace();
return(null);

42
}
}
§ Pour l'émission d'un fichier:
public static void SendFile(byte[] filedata, String fileName) {
try {
fileName = uploadingFolder + fileName;
new File(new File(fileName).getParent()).mkdirs();
File file = new File(fileName);
BufferedOutputStream output = new
BufferedOutputStream(new FileOutputStream(file));
output.write(filedata, 0, filedata.length);
output.flush();
output.close();
} catch (Exception e) {
e.getStackTrace();
}
}
3.5.2. Serveur multihome
Un serveur multihome est simplement une machine équipée de plusieurs interfaces réseau ou
adresses IP, c'est-à-dire que la machine est connectée à plusieurs réseaux, pour qu'un visualisateur
- qui situé dans un réseau quelconque – puisse connecter à cette machine; il faut savoir l'adresse IP
souhaitable parmi la liste des adresses IP du serveur. Cet algorithme fournit une méthode intelligente
qui permet au visualisateur de tester d'abord toutes les adresses du serveur et de sélectionner l'adresse
souhaitable une fois qu'une connexion est établit avec succès en utilisant cette adresse.
Pour bénéficier de cette technique, il suffit d'associer au registre RMI l'objet distant résultant du :
serverImpl = new ServerImpl(new MultihomeRMIClientSocketFactory(null,
InetAdrUtility.getLocalIPAdresses()), null);
3.5.3. Multisessions
Puisque la structure de l'application est objet; il est possible de créer autant d'instances qu'on à
besoins de n'importe quelle classe, on a bénéficié de cet avantage pour pouvoir contrôler plusieurs
PCs à partir d'un seul, ou bien de contrôler une machine par plusieurs visualisateurs en même temps.
3.5.4. Sécurité
La sécurité est parmi les propriétés les plus importantes du Java, la classe SecurityManager permet
de définir des restrictions aux accès systèmes tel que la gestion des fichiers (lecture, écriture,
exécution, suppression…etc.), les permissions pour établir des connexions, et l'utilisation de la queue
d'événements visuels…etc.
L'échange de données peut être protégé par le protocole sécurisé SSL qui fournit un canal de
communication sécurisé entre le visualisateur et le serveur; les classes SslRMIClientSocketFactory
et SslRMIServerSocketFactory permettant d'utiliser SSL pour les communications avec RMI
La prochaine instruction permet de créer l'objet distant sécurisé:

43
serverImpl = new ServerImpl(
new SslRMIClientSocketFactory(),
new SslRMIServerSocketFactory(null, null, true));
La protection du registre RMI, contre les accès non désirées se fait par:
registry = LocateRegistry.createRegistry(port,
new SslRMIClientSocketFactory(),
new SslRMIServerSocketFactory(null, null, true));
Les deux paramètres nuls permettant d'utiliser les protocoles et les algorithmes de cryptage par
défaut, et la valeur vrai à pour but d'obliger le client pour s'authentifier chez le serveur avant de
connecter à ce dernier.
3.5.5. Capture d'écran
La classe Robot est à l'origine faite pour la génération des tests automatisés des applications, dans ce
projet, la classe est utilisée pour capturer l'écran, déplacer la souris, émuler les touches clavier, …etc.
Voici un exemple qui montre les étapes d'une opération de capture d'écran:
1. Initialisation du rectangle de la capture;
(sélection du rectangle [0, 0, 308, 157])
0, 0 0, 308
157, 0 157, 308
2. Capture d’écran;
3. Redimensionnement du rectangle;
(diminution de 100% vers 75%)

44
4. Changement de la palette des couleurs;
(conversion de 32 bits vers 256 couleurs)
5. Changement de la qualité d’image;
(diminution de la qualité de 75 vers 25 %)
6. Conversion d’image vers un tableau
d’octets;
01001111011001
Voici la méthode qui renvoie l'écran capturé:
public BufferedImage captureScreen() {
Rectangle screenRect = new Rectangle(getScreenRect());
BufferedImage screen = robot.createScreenCapture(screenRect);
float screenScale = getScreenScale();
screenRect.width = (int) (screenRect.width * screenScale);
screenRect.height = (int) (screenRect.height * screenScale);
BufferedImage bimage = new BufferedImage (
screenRect.width, screenRect.height, getColorQuality());
Graphics2D g2d = bimage.createGraphics ();
g2d.drawImage(screen, 0, 0,
screenRect.width, screenRect.height, null);
g2d.dispose ();
return bimage;
}
La variable colorQuality représente la palette de couleurs (plein couleurs, 16 bit, 256 ou grise):
public int getColorQuality() {
return colorQuality;
}
public void setColorQuality(int colorQuality) {
switch (colorQuality) {
case COLOR_FULL: colorQuality = BufferedImage.TYPE_INT_ARGB; break;
case COLOR_16_BIT: colorQuality = BufferedImage.TYPE_USHORT_555_RGB; break;
case COLOR_256: colorQuality = BufferedImage.TYPE_BYTE_INDEXED; break;
case COLOR_GRAY: colorQuality = BufferedImage.TYPE_BYTE_GRAY; break;
}
}

45
3.5.6. Application des événements clavier et souris
La classe Robot dispose des méthodes pour l'émulation des événements clavier et souris, ces
méthodes sont: mousePress(), mouseRelease(), mouseWheel(), keyPress() et keyRelease().
L'application des événements souris est comme suit:
public void applyMouseEvent(MouseEvent evt) {
final int x = getScreenRect().x + (int) (evt.getX() / getScreenScale());
final int y = getScreenRect().y + (int) (evt.getY() / getScreenScale());
rt.mouseMove(x, y);
int buttonMask = 0;
int buttons = evt.getButton();
if ((buttons == MouseEvent.BUTTON1)) buttonMask = InputEvent.BUTTON1_MASK;
if ((buttons == MouseEvent.BUTTON2)) buttonMask |= InputEvent.BUTTON2_MASK;
if ((buttons == MouseEvent.BUTTON3)) buttonMask |= InputEvent.BUTTON3_MASK;
switch(evt.getID()) {
case MouseEvent.MOUSE_PRESSED: robot.mousePress(buttonMask); break;
case MouseEvent.MOUSE_RELEASED: robot.mouseRelease(buttonMask); break;
case MouseEvent.MOUSE_WHEEL: robot.mouseWheel(
((MouseWheelEvent) evt).getUnitsToScroll()); break;
}
}
Et l'application des événements clavier est comme suit:
public void applyKeyEvent(KeyEvent evt) {
switch(evt.getID()) {
case KeyEvent.KEY_PRESSED: robot.keyPress(evt.getKeyCode()); break;
case KeyEvent.KEY_RELEASED: robot.keyRelease(evt.getKeyCode()); break;
}
}
3.5.7. Qualité d'image JPEG
Les images de type JPEG disposent d'un facteur appelé CompressionQuality, ce facteur est un
pourcentage qui permet de spécifier la qualité d'image, où 100% représente une qualité meilleure et
0% représente une mauvaise qualité, la valeur par défaut de ce facteur est 75%. Voici l'algorithme
qui permet d'appliquer la qualité d'image JPEG sur une image fournit en paramètre, la variable
quality représente le facteur de compression et la variable out est le flux de sortie.
public static void write(BufferedImage image,
float quality, OutputStream out) throws IOException {
Iterator writers = ImageIO.getImageWritersBySuffix("jpeg");
if (!writers.hasNext()) {
throw new IllegalStateException("No writers found");
}
ImageWriter writer = (ImageWriter) writers.next();
ImageOutputStream ios = ImageIO.createImageOutputStream(out);
writer.setOutput(ios);
ImageWriteParam param = writer.getDefaultWriteParam();
if (quality >= 0) {
param.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
param.setCompressionQuality(quality);
}
writer.write(null, new IIOImage(image, null, null), param);

46
ios.close();
writer.dispose();
}
3.5.8. Compression de données
Le paquetage java.util.zip forunit divers outils et algorithmes de compression et de décompression,
les classes Deflater et Inflater sont des classes de base de la compression.
3.5.9. Configuration
A titre d'information; voici la classe responsable de la configuration; deux méthodes – une pour la
lecture et l'autre pour l'écriture – sont utilisées pour communiquer avec le fichier de la configuration
du jrdesktop qui est appelé "config", le fichier est automatiquement créer, s'il n'existe pas.
public class Config {
public static boolean GUI_disabled = false;
public static boolean Systray_disabled = false;
public static void loadConfiguration() {
if (new File(main.CONFIG_FILE).canRead())
try {
Properties properties = new Properties();
properties.load(new FileInputStream("config"));
GUI_disabled= Boolean.valueOf(properties.getProperty("GUI-disabled"));
Systray_disabled= Boolean.valueOf(properties.getProperty("Systray-disabled"));
}
catch (Exception e) {
e.getStackTrace();
}
else
storeConfiguration();
}
public static void storeConfiguration () {
try {
new File(main.CONFIG_FILE).createNewFile();
Properties properties = new Properties();
properties.put("GUI-disabled", String.valueOf(GUI_disabled));
properties.put("Systray-disabled", String.valueOf(Systray_disabled));
properties.store(new FileOutputStream(("config"), "jrdesktop configuration");
} catch (Exception e) {
e.getStackTrace();
}
}
}
4. Conclusion
On a présenté dans ce chapitre la modélisation par UML du jrdesktop où on a montré les diagrammes
UML (diagramme de cas d'utilisation, de classe, de composant et digramme de déploiement).
Ensuite, On a présenté une description architecturale générale et détaillée de système et la procédure
de la communication entre les modules. Ainsi; on a cité quelques fonctionnalités de base de notre
application.

CHAPITRE IV Déploiement du système
47
Chapitre IV
Déploiement du système
« Le meilleur n’est atteint qu’au dépend d’une grande douleur.»
1. Introduction
L’étape de conception était achevée, notre système (ce qu’on a appelé « jrdesktop », abréviation
de Java Remote desktop) à été implémenté et validé. Nous allons donc passer à le déployer et de le
décrire, cette application à été écrit en Java à l’aide de NetBeans. Son but est de surveiller et/ou
contrôler un PC à distance.
Outre l'envoi des captures d’écran de poste contrôlé, et l’envoi
des touches claviers et mouvements sourie de poste contrôleur, jrdesktop comprend de nombreuses
autres fonctionnalités (transfert de fichiers, compression des données, conversion de couleur, ...).
Java Remote Desktop est destiné à fonctionner sur différentes plates-formes (basé sur JVM), ces
principales caractéristiques sont les suivantes :
· Captures d'écran en temps réel de l'ordinateur distant et possibilité de le contrôler en
transférant des événements clavier et mouvements souris ;
· Fonctions de contrôle: marche / arrêt, pause / reprise de lecture, observation seulement/ plein
contrôle ;
· Fonctions écran: plein écran / fenêtré (taille personnalisé), ajusté (échelle d’écran) ;
· Compression des données (avec sélection de niveau de compression) ;
· Qualité de la compression d’image JPEG (avec la sélection de niveau) ;
· Contrôle de la qualité couleur (pleine couleurs, 16 bits, 256 couleurs, couleur grise) ;
· Transfert de presse-papiers (textes et images seulement) ;
· Transfert de fichiers (de petites tailles);
· Statistiques sur la connexion: durée, taille des données transférées, vitesse;
· Authentification, sécurité et cryptage de données;
· Multisessions (Connexions multiples).

48
Dans ce qui suit, nous indiquons d’abord l’environnement de programmation, ce qui
comprend: le véritable langage de programmation Java , la technologie RMI pour la
communication, le protocole SSL pour la sécurité et l’IDE NetBeans. Après, nous montrons par
des captures d’écran l’utilisation du système. Ensuite, on montre une étude de qualité du logiciel
développé ainsi les tests et résultats de ces tests qui ont été faites sur le transfert des données entre
le contrôleur et le contrôlé. Enfin, on terminera par représenter une vue générale sur les sites web
qui ont publiés notre logiciel, ainsi des statistiques de téléchargement de notre application
hébergé sur le site de sourceforge.net.
2. Environnement de développement
Avant de commencer à insister sur comment utiliser notre système, nous allons tout de
même mentionner les outils et les technologies utilisés (détaillés précédemment en 2ème
chapitre) qui
nous ont semblés être un excellent choix comme base pour nos développements de part les
avantages qu’ils offrent.
Notre projet est développé en Java afin d'assurer une meilleure portabilité. Les utilisateurs ne seront
donc pas restreints à utiliser un seul système d'exploitation. Le langage Java est un langage de
programmation orienté objet basé sur la portabilité et la réutilisabilité de son code ainsi que
la simplicité de sa mise en œuvre. Java intègre l'encapsulation, l'héritage, la liaison dynamique des
classes de programmes et il permet la programmation multithread, la programmation réseau
sous le schéma client/serveur et intègre dès la conception plusieurs mécanismes de sécurité,
visant à rendre les programmes fiables et à éliminer les risques de virus.
L'application est programmée avec la dernière version du Java SE 6 mise à jour 6 (JDK 6 Update 6).
Nous avons opté comme outil de développement intégré pour Java la plus récente version 6.1 de
NetBeans (version actuelle), et nous avons choisi RMI pour invoquer à distance les méthodes de
notre application, ainsi le protocole SSL (Secure Socket Layer) pour établir une connexion sécurisée
entre le module Admin et le module Hôte. L'exécution de l'application et les tests de vérification
durant le développement sur une même machine ont été établis par VMware Workstation 6.
3. Utilisation du système
On va procéder à la description par des schémas de capture d’écran de notre application bureau
distant.
3.1. Procédure d'obtention de Java Remote Desktop
La plupart des logiciels informatiques offrent une possibilité d’installation pour le déploiement et
l'établissement d'une configuration adaptée au système choisi.
jrdesktop est fournit en un seul fichier compressé (jrdesktop.jar) d'une taille qui ne dépasse pas 300
KB, aucune installation est nécessaire, le fichier est exécutable à tout systèmes où java est installé. La
plus récente version développée est jrdesktop 0.2.0020 du 23 mai 2008. L'application est fournie
gratuitement par le site web jrdesktop.sourcefourge.net.
Avant de lancer jrdesktop par la ligne de commande ou un simple double clique, il faut savoir que
cette application est développée sous Java, elle nécessite que l’ordinateur soit équipé d’une machine
virtuel Java (JVM) pour qu’elle fonctionne. Pour ce la, il vaut mieux utiliser une version plus récente

49
de JRE (Java Runtime Environment) qui est la 6u6 (6éme
version, 6éme
mise à jour) et qui est
disponible et gratuite. Pour l’obtenir, il suffit de « surfer sur le Net » ou de la télécharger à partir de
site de Sun Microsystems : sun.com ou bien le site java.com.
L'installation de cet environnement d'exécution des applications Java (JRE) est un processus simple,
quel que soit le système d'exploitation (Windows, Linux, Solaris ou autre).
3.2. Interface utilisateur (vue générale de l’IHM)
L’interface de système est illustrée par des schémas qui montrent les fonctions offertes à savoir :
· Des boites de dialogues permettant d’utiliser cette application facilement.
· Un menu contextuel qui permet de mieux utiliser l’application (configurer, consulter, lancer le
module Hôte, etc.) ;
· Une barre d’icônes qui comprend sous forme visuelle les fonctionnalités à utilisées par des
icônes, des menus déroulants (combo-box), des cases à cocher et une barre de réglages ;
· Des boites de messages signalant les principaux événements ;
· Des infos bulle (bulle d’aide) montre des petits textes explicatifs ; très utiles pour déterminer la
raison d'être dans tel ou tel état (indication d'état).
Rappelons que notre application se décompose en deux parties, l’Admin (client) et l’Hôte (serveur).
L'Hôte est le programme esclave sur la machine qui partage son écran, et l’Admin est le programme
maître qui regarde et interagit éventuellement avec l'Hôte.
3.2.1. Fenêtre principale de jrdesktop
Après le lancement de l’application, une fenêtre s’ouvre comme le montre la figure suivante :
Figure 4.1 – Apparence la fenêtre principale de jrdesktop
Dans la fenêtre principale (Cf. Figure 4.1) on peut accéder au :
§ (1): Lancement (ou arrêt) de l’Hôte par le bouton « Start » (ou « Stop »);
§ (2): Configuration de l’Hôte par le bouton « Configuration » ;
§ (3): Gestion des connexions actives par le bouton « Active connections… » ;
§ (4): Envoie ou reçois de fichiers par le bouton « File transfert ».

50
§ (5): Zone de texte permettant de connaître le statut (état) de l’Hôte (en marche ou en arrêt),
ainsi de savoir l’adresse IP et le port utilisé et savoir aussi à ce que l’authentification, cryptage
et la fonction « multihomed » sont elles activées ou pas.
Les fonctions précédentes concernent le module Hôte (le serveur jrdesktop).
§ (7): Connexion (pour contrôler ou surveiller) à un serveur distant en utilisant le bouton
« Connect to Server »;
§ (8): Ouverture de la boite de dialogue "A Propos";
§ (9): Fermeture (quitte) de l’application ;
§ (10): Apparition ou non de la fenêtre principale lors de démarrage de l’application ;
§ (11): Cacher ou montrer l’icône de la barre des tâches.
3.2.2. Icône de la barre des tâches
Au lancement de l’application un icône va apparaître sur la barre des tâches :
Figure 4.2 – Apparition de l’icône sur de la barre des tâches
Au lancement, arrêt ou à l'échec du l’Hôte, et où connexion (ou de déconnexion) d'un utilisateur
Admin; une info bulle apparaît près de l’icône de l’application sur la barre des tâches indique cet
événement (Cf. Tableau 4.1) :
Info bulle Etat
L’Hôte est correctement lancé.
Echec du lancement du l’Hôte.
Un utilisateur Admin est vient de se
connecté.
Un utilisateur Admin est vient de se
déconnecté.
Le serveur est correctement arrêté.
Tableau 4.1 – Les différentes infos bulle inadéquates les divers événements
L’icône de l’application

51
L'icône de la barre des tâches montre l'état du module Hôte, il est automatiquement changé chaque
fois que l’Hôte change (lancé ou pas, soit qu’il est contrôlé ou surveillé) (Cf. Tableau 4.2).
Icône
Description
Le module Hôte n’a
pas encore été lancé.
Le module Hôte
est en écoute.
Le module Hôte est actif
(il est contrôlé ou surveillé)
Tableau 4.2 – Les déférents changements de l’icône de la barre des tâches
3.2.3. Menu contextuel
L’application est dotée d’un menu contextuel englobant les fonctionnalités de l’application comme
on peut le constater dans la figure 4.3. Le menu est divisé en 4 partis dont 2 sont essentielles : une
concerne l'Hôte et l’autre concerne l'Admin.
Ce menu peut être utilisé à la place de la fenêtre principale. Il peut être vu comme un raccourci vers
les fonctionnalités de base du jrdesktop.
Figure 4.3 – Le menu contextuel de jrdesktop
La sélection de « Open jrdesktop » dans ce menu permet d’ouvrir la fenêtre principale. La même
action est générée par un double clique sur l'icône (dans la barre des tâches) de l'application.
3.2.4. Fenêtre de contrôle de l’application jrdesktop
L’apparence globale de l’application développée est illustrée par la capture d’écran suivante (Cf.
Figure 4.4), dont elle représente l’interface de module Admin qui montre l’écran de l’ordinateur
distant.
Cette fenêtre de contrôle est composée :
· d'une barre de titre qui affiche l'adresse de l'ordinateur distant;
· d'une barre d’outils qui englobe les composants visuels (widgets);
· d'une zone qui montre l’écran de module Hôte;
· des barres de défilement pour la possibilité de voir l'écran distant tout entier.
Outre les barres de défilement, l'utilisateur peut redimensionner la fenêtre selon ses besoins.

52
Figure 4.4 – Aperçu général de la fenêtre de contrôle à distance de l’utilisateur Admin
a- Barre d’outils
Cette barre regroupe des boutons d’accès rapide aux différentes fonctionnalités de l’environnement,
des menus déroulants et des cases à cocher pour sélectionner un élément de paramétrage de système
et une barre de réglages de qualité d’image (Cf. Figure 4.5 et Tableau 4.3).
Figure.4.5 – barre d’outils de l’application
Widgets Aperçu Activité (Fonction)
Boutons
/ Permet d’arrêter ou commencer la visualisation et/ou le contrôle.
Faire pauser ou rependre la visualisation et/ou le contrôle.
/ Contrôle total ou observation seulement. de PC Hôte.
/
Affichage en plein écran ou par une simple fenêtre de l'écran de
PC Hôte.
Surveillance personnalisée : sélectionner avec le curseur une zone
déterminée de l’écran de PC Hôte pour la visualiser.
Transfert d’un fichier (envoie ou recevoir) mise en presse-papiers.

53
Consulter les propriétés système de PC contrôlé.
Consulter les détailles de connexions au ordinateur Hôte.
Ce qui nous concerne en tant que réalisateurs de logiciel, la
version et le site a consulté pour en savoir plus.
Menus
déroulants
Choisirez la taille de l’écran de PC Hôte en pourcentage (25, 50,
75, 100, 125, 150, 75 et 200%).
Choisirez une compression déterminée (meilleur, rapide, par
défaut ou stockage seulement).
Choisirez le nombre de couleurs (pleine couleurs, 16 bits, 256
couleurs ou couleur grise).
Cases à
cocher
Activer ou désactiver la compression des données.
Activer ou désactiver la qualité de la compression d’image JPEG.
Activer ou désactiver la mise en tampon de presse-papiers.
Barre de
réglage
Fixer le niveau de la qualité de la compression d’image JPEG.
Tableau 4.3 – Les composants de la barre d’outils et leurs activités
Des infos bulle (bulle d’aide) montre l’action à faire de chaque composant de contrôle (boutons,
cases à couché, listes déroulante et barre de réglage). (Cf. Figure 4.6)
Figure 4.6 – Infos bulle explicative
b- Zone de visualisation
C’est la zone d’affichage de l’écran de l’ordinateur Hôte. C’est la surface de travail dont dispose
l’utilisateur qui lance le module Admin de faire soit l’observation soit le contrôleur de la machine
Hôte en utilisant le clavier et la sourie. C’est dans cette zone que le contrôleur intervient pour faire à
distance un travail déterminé, une maintenance ou n’importe qu’elle fonction utilisé comme si il est
sur son poste lui même.
c- Sélection partiel d'écran
jrdesktop offre la possibilité de voir une partie spécifique de l'écran de l’Hôte. Pour cela, il suffit de
cliquer sur le bouton ; immédiatement le curseur change sa forme en précision . Lorsque
l'utilisateur clique sur un endroit, le rectangle de sélection apparait. Après que la zone désirée est
sélectionnée (Cf. Figure 4.7), il suffit de relâcher le bouton de la souris pour que la capture partielle
devienne active (Cf. Figure 4.8). L'avantage de cet outil est de minimiser le trafic de données et
d'accélérer le bureau distant par la transmission de la zone désirée de l'écran seulement. La
restauration vers l'affichage par défaut est faite par le bouton .

54
Figure 4.7 – La sélection est en cours
Figure 4.8 – Après la sélection

55
d- Affichage en plein écran
Cette option permet à l'utilisateur de passer en mode plein écran, (par un clique sur bouton ) cela
permet de voir seulement la zone de visualisation et la barre d'outils. La barre de titre est désactivée,
la fenêtre est au-dessus de toutes les fenêtres ouvertes, ainsi la barre des tâches. L'affichage normal
est fait par un clique sur le bouton (Cf. Figure 4.9).
Figure 4.9 – Affichage en plein écran
e- Changement d'échelle d'écran
L'utilisateur peut changer l'échelle de visualisation (Cf. Figure 4.10) par diminution (de 75 jusqu'au
25%), soit par augmentation (de 125 jusqu'au 200 %).
Figure 4.10 – Vue minime d'écran (échelle 1/2)

56
f- Palettes de couleurs
A pour but d'optimiser l'affichage par la spécification de la qualité du couleur voulue (Cf. Tableau
4.4), L’utilisation de la couleur grise – par exemple - à pour avantage de voir l'écran clairement avec
une petite occupation de la bande passante par apport aux couleurs vrais (jusqu'au 50 % gain dans le
cas où la qualité de la compression d'image JPEG est désactivée).
Couleurs vrais 16 Bits
Couleur grise 256 Couleurs
Tableau 4.4 – Comparaison des différentes palettes de couleurs
g- Qualité de la compression d'image JPEG
Si l'utilisateur voit que la qualité d'image n'est pas satisfaite, il peut essayer d'activer ce paramètre et
d'augmenter la qualité (Cf. Tableau 4.5). Au cas contraire, si le transfert est lourd, l'utilisateur peut la
diminuer.

57
100 % 75%
25% 0 %
Tableau 4.5 – Comparaison de la qualité de la compression d'image JPEG
h- Transfert du contenu du presse-papiers
Pour faciliter la collaboration en ligne et le travail en groupe, cette fonctionnalité permet de transférer
le contenu du presse-papiers – sous forme des textes ou des d'images - d'un PC à un autre, il suffit de
sélectionner l'objet, de le copier vers la mémoire (par Ctrl+C par exemple) de le coller (par Ctrl+V
par exemple) dans le programme d'édition du texte ou de traitement d'image désiré au PC distant.
La figure suivante 4.11 montre le transfert d'un histogramme – sous forme d'une image – à partir d’un
fichier Word – de l'ordinateur local - vers le logiciel de dessin MS Paint de l'ordinateur distant.

58
Figure 4.11 – Transfert d'une image à l'aide du presse-papiers
3.3. Configuration de module Hôte
Si l’utilisateur de l’application veut être contrôlé ou surveillée à distance par un autre utilisateur
exécutant le module Admin de l’application alors avant de procéder au lancement de module Hôte, il
est conseillé de le configuré en sélectionnant « Server Configuration » dans le menu contextuel (Cf.
Figure 4.3) ou l’appuie sur le bouton « Configuration » dans la fenêtre qui le montre la figure 4.1.
La configuration de module Hôte comme le montre la figure 4.12 permet d’entrer : une adresse IP de
l’ordinateur local, un port (par défaut 6666) dont on établit la communication avec le module Admin,
un nom d’utilisateur avec mot de passe pour éviter les accès distants non autorisés, en plus cette
configuration permet de choisir d’autres fonctions:
· Configuration manuelle : en cochant la case « Manual », elle permet de choisir (d'une façon
précise) une adresse IP parmi une liste des adresses de la machine, et d’entrer un numéro de
port.
· Mettre l'adresse manuellement choisie comme l'adresse par défaut de la machine virtuelle
(lorsque qu'on fait cocher la case « Default »), cette option permet d'aider les applications
java à utiliser une adresse déterminée pour tout type de communication.
· Détection automatique des adresses IP : lorsque on fait cocher la case « Auto detect
(Multihomed server) », le programme choisit une adresse IP par défaut parmi les adresses

59
locaux. Cette option est très utile et à pour but d'aider les utilisateurs Admin pour choisir une
adresse IP souhaitable du l’Hôte pour communiqué avec ce dernier.
· Pour garantir la sécurité de la communication, l'utilisateur peut activer et utiliser le protocole
de cryptage SSL.
Figure 4.12 – Boîte de dialogue de configuration de module Hôte
Les modifications apportées sont enregistrées dans un fichier de configuration pour éviter la
spécification des paramètres souhaités chaque fois qu'on veut utiliser le module Hôte de jrdesktop.
3.4. Connexion au module Hôte depuis le module Admin
Pour qu’un utilisateur puisse faire connecter à l'ordinateur Hôte il faut qu’il sache son adresse IP, le
port à utiliser et pour l’authentification le nom d'utilisateur et son mot de passe, ainsi pour augmenter
la sécurité, une possibilité d’utiliser SSL. La figure suivante montre ces détails (Cf. Figure 4.13)
Figure 4.13 – Etablissement des détailles pour connecter au module Hôte
Après la validation par « OK », si l'ordinateur Hôte est atteignable, et le port, le nom, le mot de passe
et optionnellement la sécurisation de la connexion sont équivalents aux paramètres par défaut du
module Hôte ; la connexion va être établie et une fenêtre va apparaître où elle visualise l’écran de
l’ordinateur distant ce qui permet de le contrôler (Cf. Figure 4.4).
Si la connexion est échouée, un message d'erreur est signalé indiquant la cause.
Pendant la session; l'utilisateur maître à le droit d’utiliser deux modes de contrôle à distance:

60
1. Le mode « Observation » (surveillance) : ne permet que la visualisation de l'ordinateur distant.
2. Le mode « Contrôle Total » : permet de piloter l'ordinateur avec la souris et le clavier. Le
contrôleur peut gérer les programmes et les fichiers de l'ordinateur distant, ainsi que de les
transférer dans son PC, d'imprimer des documents, d'accéder au réseau local et de se surfer sur le
web … etc.
3.5. Connexions actives
L’application jrdesktop assure des sessions multiples, c'est-à-dire de multiples connexions
simultanées. En effet, Le module Hôte supporte plusieurs connexions simultanément, au même
temps, l'utilisateur peut observer/contrôler plusieurs PCs à la fois (en utilisant des instances du
module Admin). Il est également possible d'observer simultanément un même PC depuis plusieurs
postes différents (Cf. Figure 4.14).
Figure 4.14 – Consultation des PC Admin connectés en cours
Plusieurs activités sont à la main du l’Hôte pour savoir des d'information sur tous les utilisateurs
Admin connectés et de les contrôlés (figure 4.13):
· Consulter (en cliquant sur le
bouton « Details ») des
informations détaillées de leurs
connexions (la durée, quantités de
données envoyées et reçues et la
vitesse de transfert). (Cf. Figure
4.15)
Figure 4.15 – Détails de la connexion

61
· Voir (en cliquant sur le bouton
« Properties ») les propriétés
d'ordinateur connecté: son nom,
son adresse IP, version Java
installée, le système
d’exploitation, le nom d'utilisateur
connecté et son dossier actif, la
résolution et la taille d’écran (Cf.
Figure 4.16).
Figure 4.16 – Propriétés de l'ordinateur distant
· Déconnecter un utilisateur ou touts entièrement par « Disconnect » « Disconnect all».
3.6. Transfert de données
Le transfert de données permet de transférer soit du presse-papiers soit de fichiers entiers.
3.6.1. Transfert du contenu du presse-papiers
Le presse-papiers contient des informations récupérées par diverses applications. Au cours d'une
session ouverte, vous pouvez transférer les textes ou les graphiques contenus dans le presse-papiers
de l'ordinateur Hôte vers l'ordinateur distant ou vice-versa.
3.6.2. Transfert de fichiers et de dossiers
jrdesktop permet de transférer des fichiers et des dossiers vers et depuis un autre ordinateur distant.
Ce transfère est lancé en cliquant sur « Send (ou Receive) Files » à l'ordinateur local, après avoir mit
des fichiers et/ou des dossiers au presse-papiers de l'autre ordinateur.
Le transfère peut être aussi fait par glissage des fichiers et/ou des dossiers sur la fenêtre de la
visualisation. Une fenêtre indique l’état de transfert : temps écoulé en seconde et pourcentage, vitesse
en kb/s, taille de fichier et ainsi le répertoire où se trouve ce fichier. Le transfert de fichiers
n'empêche pas la visualisation de se continuer; d’autres fichiers et/ou dossiers peuvent être
parallèlement transférés (Cf. Figure 4.17).
Figure 4.17 – La fenêtre du transfert de fichiers

62
a- Le transfert de fichiers effectué par l’ordinateur Admin
L’ordinateur Admin doit être en session c'est-à-dire de connecter à l'ordinateur Hôte pour réaliser un
transfert de fichiers, il peut choisir l’un des deux préférences de transfert suivantes :
1. Glisser-déposer : on clique sur un dossier ou un fichier à envoyer, maintenir le bouton
gauche enfoncé, puis déplacer la souris et lâcher le bouton une fois arrivé à la zone Hôte
(espace d’affichage d’écran de l’Hôte).
2. l’icône de transfert de la barre d’outils : on clique sur l’icône de transfert de la barre
d’outils (Cf. Figure 4.5) pour choisir d’envoyer un fichier placé dans le presse-papiers vers le
PC distant ou reçois un fichier placé dans le presse-papiers par l’utilisateur Hôte.
b- Le transfert de fichiers effectué par l’ordinateur Hôte
Par le menu contextuel en sélectionnant « File transfert » l’utilisateur Hôte peut soit envoyer ou
reçois des fichiers ou des dossiers placés dans le presse-papiers de l'ordinateur Admin.
Il faut savoir que jrdesktop permet de transférer de textes ou des images en utilisant seulement
copier-coller ou couper-coller de presse-papiers.
3.7. Utilisation par ligne de commande
L'interface en mode caractère (texte) à été introduite pour le lancement de jrdesktop par la ligne de
commande ce qu’il offre des avantages tel que :
· Lancement automatique de module Hôte (par exemple au démarrage de PC).
· Utile pour les systèmes qui ne supportent pas le taskbar (appelé aussi systsme tray) (icône
dans la barre des tâches).
· Fichiers patches (scripts qui contient des commandes dos ou shell) peut être crées pour éviter
la frappe des commandes à chaque utilisation de jrdesktop.
Pour se faire on lance la fenêtre de MS-DOS (ou un terminal sous linux par exemple) en tapant les
commandes du jrdesktop et on valide par Entrée (Cf. Figure 4.18).
Les commandes sont:
· display affichage de la fenêtre principale.
· server lancement du serveur avec les paramètres par défaut.
· viewer lancement du visualisateur avec les paramètres par défaut.
Les paramètres par défaut sont l'adresse de la machine locale et le port 6666.
Les options disponibles sont:
· -a:address L'adresse du serveur;
· -p:port Le port du serveur;
· -u:username Le nom d'utilisateur;
· -d:password Le mot de passe d'utilisateur;
· -s Sécurisation de la connexion avec SSL;
· -m Serveur multi-home;
· -version Affichage de la version du jrdesktop;
· -help ou ? Affichage du l'aide.

63
Figure 4.18 – Affichage du l'aide du jrdesktop par la ligne de commande
Exemple de scripts:
· Affichage de la fenêtre principale du jrdesktop:
java -jar jrdesktop.jar display
· Lancement du serveur en utilisant les paramètres par défaut:
java -jar jrdesktop.jar server
· Connexion à un serveur jrdesktop:
java -jar jrdesktop.jar viewer
· Lancement d'un serveur multihomed, avec le port 8888, "admin" comme un nom d'utilisateur,
"pwd" comme un mot de passe et avec une connexion sécurisée SSL:
java -jar jrdesktop.jar -p:8888 -u:admin -d:pwd -s –m
· Connexion au serveur 192.168.1.2, avec le port 8888, "admin" comme un nom d'utilisateur,
"pwd" comme un mot de passe et avec une connexion sécurisée SSL:
java -jar jrdesktop.jar -a:192.168.1.2 -p:8888
-u:admin -d:pwd –s
Avant d'utiliser ces commandes et ces options, il est conseillé de lancer la commande "java" toute
seule pour savoir s'elle reconnu ou non. Dans le cas contraire, l'utilisateur doit ajouter le chemin où
java.exe est installé (par exemple "C:Program FilesJavajdk1.6.0_06bin") au variable
d'environnement PATH (consulter le guide d'installation du JDK pour plus de détails).
3.8. Messages d'erreur
Lords de l'utilisation de jrdesktop; plusieurs erreurs peuvent être apparaitre. Comme l'erreur ci-dessus
qui montre l'échec de la connexion à cause de dépassement de délai (Cf. Figure 4.19).

64
Figure 4.19 – Exemple d'un message d'erreur
Le tableau suivant (Cf .Tableau 4.6) montre les principaux messages d'erreur, sauf les 3 derniers
messages ; les erreurs sont automatiquement générées par la machine virtuelle Java. Il est préférable
de mettre des messages personnalisés pour faciliter à l'utilisateur la compréhension de la nature des
erreurs, mais à cause de la diversité et la multiplicité de ces messages; on a laissé les messages tels
qu'ils sont.
DescriptionErreur
Hôte non atteignable, adresse ou port inexistant.No route to host: connect
Délai d'établissement de la connexion est écoulé.Connection timed out: connect
Echec lors d'établissement de la connexion, l'utilisateur
n'a pas suffisamment de droits d'accès au serveur.
Connection refused: connect
Echec lors d'établissement de la connexion, Adresse et
port déjà occupés par une autre application.
Address already in use: JVM_BIND
Port already in use: 6666
Echec lors d'établissement d'une connexion sécurisée
vers un serveur non sécurisé.
Remote host closed connection
during handshake
Echec lors d'établissement d'une connexion non
sécurisée vers un serveur sécurisé.
Non-JRMP server at remote endpoint
Echec lords de l'authentification, le nom et/ou le mot de
passe de l'utilisateur sont étonnés.
Wrong username or password
Icône dans la barre des tâches est non supportée.Systray not supported
Echec lors de transfert de fichiers, le presse-papiers ne
contient aucuns fichiers.
No file in clipboard
Tableau 4.6 – Les messages d'erreurs les plus fréquentés du jrdesktop
4. Etude de qualité du logiciel (Evaluation)
Cette partie va décrire une simple évaluation de notre application jrdesktop.
4.1. Avantages du logiciel :
Le contrôle à distance peut être utile pour plusieurs raisons. Notre application développée comporte
plusieurs points forts, on cite :
1. Interface utilisateur conviviale et intuitive ;
2. Haute vitesse et performance dans les réseaux LAN en raison de la compression des données
et de qualité d’image et des algorithmes optimisés ;
3. Ecran de PC Hôte redimensionnable et facile à utiliser. Différents modes de couleur
disponibles pour s'adapter au mieux à la bande passante disponible ;
4. Support clavier international ;

65
5. Forte de sécurité et de haute sécurité. SSL et un protocole d'authentification de type
algorithme de cryptage en fait un programme d'utilisation absolument sûre ;
6. Authentification, par l'utilisation d'un nom et d'un mot de passe.
7. De multiples connexions simultanées. Avec cette fonctionnalité, l'administrateur réseau peut
assurer efficacement le contrôle à distance des PC différents simultanément. En outre, deux
ou plusieurs administrateurs peuvent contrôler un ordinateur distant à la fois ;
8. Transfert de fichiers, de textes et des images (à l'aide de presse-papiers);
9. On n’a jamais eu le besoin d’accéder à 2 PC en même temps sans avoir d’écran
supplémentaire et donc sans avoir besoin de jongler avec votre prise VGA !
10. jrdesktop est indépendant de la plateforme - grâce à la machine virtuelle JVM - : il est
possible de contrôler des machines de différents systèmes, comme montre la figure 4.20 où
un PC sous Windows XP contrôle un PC équipé de la distribution PCLinuxOS 2007, et la
figure 4.20 où on contrôle un PC sous Windows Vista depuis un PC sous Mac OS X 10.5.3.
Figure 4.20 – PC sous Mac OS X 10.5.3 contrôle un PC sous Windows Vista
4.2. Limitations du logiciel :
Les points faibles de notre application sont :
1. Occupation élevée de la bande passante (jrdesktop est très peu fiable aux réseaux WAN de
basse vitesses);

66
2. Occupation élevée de ressources matérielles (mémoires et CPU), ce problème est commun à
toutes les applications Java dû à la couche virtuelle (JVM) ;
3. Transfert des captures d'écran et des mouvements souris et du contenu de presse papiers
même si la fenêtre de visualisation est inactive ou invisible ;
4. Réglage des paramètres de visualisation (nombre de couleurs, qualité de la compression
d'image JPEG, taille d'écran) à chaque nouvelle session ;
5. Manque de la documentation API du code source et des documentations du projet.
6. Transfert de presse-papiers est partiel (dû au support minime du presse-papiers par Java) ;
7. Transfert de fichiers est limité aux fichiers de petites tailles (moins de 32 MB) et occupe la
mémoire ;
8. Pas de client Web (support de visualisation par des navigateurs Internet) ;
9. Pas de support de Proxy, ni de tunnel http et l’absence d'un relai.
4.3. Tests et résultats du transfert de données
Dans cette partie on va effectuer des différents tests sur notre application, pour savoir la taille des
données transférées entre l'Admin et l'Hôte, on présente surtout l'effet de la compression de données
et la qualité de compression d'image JPEG et le nombre de couleurs sur la taille des données
transférées.
Les tests sont faits dans un PC équipé d'un processeur Intel Core 2 CPU 6300 1.86 GHZ avec une
mémoire de 1 GB et un disque dure SATA de 160 GB (pour la visualisation) connecté – par un
réseau LAN virtuel - à une machine virtuelle (acte comme un serveur jrdesktop) de VMWare
Workstation équipé d'une mémoire de 256 MB avec un écran de dimension 800x600 pixels. Les deux
PCs tournent sur Windows XP SP3. La réalité est que le processeur est partagé entre les deux
systèmes d'exploitation et la mémoire de la machine virtuelle fait partie de la mémoire centrale du PC
Admin (1GB – 256 MB = 768 MB).
4.3.1. Envoie des données par le module Admin
Les données envoyées vers le serveur sont: les événements souris et clavier, le contenu du presse-
papiers - en cas du changement de son contenu-, la liste des fichiers à envoyer et d'autres commandes
– de petites tailles -. Dans le cas d'une utilisation ordinaire du bureau disant; seules les événements
souris sont transportés vers le Hôte. Toutes les autres données sont négligeables par rapport aux
événements de la souris qui dépassent parfois un total de 300 événements dans un seul transfert. En
générale; la durée moyenne d'un envoi est 16 ms.
L'histogramme ci-dessous (Cf. Figure 4.21) montre l'effet de la compression sur les données
envoyées à travers une comparaison faite sur 10 tests aléatoires.

67
Figure 4.21 – L'effet de la compression sur les données envoyées
Tandis que les tests indiquent une petite taille de données (9 éme
, 3 éme
et 5éme
tests par exemple)
montrent des petits mouvements de la souris, les tests avec des tailles élevées de données
représentent un déplacement très rapide de la souris (10éme
, 2éme
et 8éme
tests par exemple). Le 1er
test indique l'absence d'événements souris.
Le gain de la compression en pourcentage est obtenu à partir du rapport calculé de la taille de
données compressées (en bits) sur la taille de données non compressées (en bits), voici l’histogramme
suivant (Cf. Figure 4.22) qui montre le gain des 10 tests réalisés :
Figure 4.22 – Gain de la compression en pourcentage (%)

68
Analyse et interprétation :
Le premier test (Cf. Figure 4.21) montre l'influence des événements de la souris (mouvements,
clique, glissement …etc.) sur les données envoyées. Ainsi que l'effet de la compression sur ces
données. Tandis que le nombre d'événements augmente, la taille de données augmente en parallèle.
Le deuxième graphique (Cf. Figure 4.22) test montre le gain de la compression qui peut atteindre 70
% dans le cas où le nombre des événements de la souris augmente. Le gain de compression varie
entre 50 et 70%.
Donc, on conclue que la compression joue un rôle très important car une donnée compressée
nécessite moins de temps pour son transfert - malgré le processus de compression et de
décompression-, et occupe moins de la bande passante ce qui rend l’application plus efficace.
4.3.2. Réception des données par le module Hôte
Les données recueillies de l'hôte sont: la capture d'écran, la taille d'écran, le contenu du presse-
papiers, la liste des fichiers à transmettre et quelques autres commandes. Dans le car ordinaire; seules
les captures d'écran sont reçues. Le test ci-dessous (Cf. Figure 4.23) montre l'effet de la compression
de données, la qualité de la compression d'image JPEG et le changement des palettes des couleurs sur
la taille des données reçues.
16 différents tests ont été faits, dont 4 tests pour chaque palette de couleur (plein couleurs, 16 bits,
256 couleurs et couleur grise). Pour chaque palette de couleur on change le niveau de la qualité de la
compression d'image JPEG (0%, 50%, 100% et 75%). Le dernier niveau (75%) représente la valeur
par défaut, où la compression est désactivée.
Le temps occupé par le transfert est varié - en moyen 317 ms – dû à l'influence de plusieurs facteurs
(occupation du CPU et de la mémoire, trafic de la bande passante, compression, nombre de
couleurs…etc.).
Figure 4.23 – Effet de la qualité de la compression d'image JPEG

69
Le gain de la compression en pourcentage est obtenu à partir du rapport calculé de la taille des
données compressées (en bits) sur la taille des données non compressées (en bits), voici
l’histogramme qui montre le gain des 16 tests réalisés (Cf. Figure 4.24).
Figure 4.24 – Gain de la compression en pourcentage (%)
Analyse et interprétation :
On voit que la configuration avec 256 couleurs et 100% de la qualité de la compression d'image
JPEG occupe beaucoup la bande passante (cas exceptionnel), donc le test correspondant est
négligeable.
Le gain retenu est au tour de 50% lorsque la qualité de la compression d'image est au tour de 0%, et il
peut atteindre jusqu'au 67% avec la palette pleine couleurs. Cette situation est rarement utilisée dû à
la mauvaise qualité d'images. Alors cette configuration est retirée du test (cas exceptionnel).
On remarque clairement que la compression n'influe presque pas sur la taille des données reçues, car
les images reçues sont de type JPEG, c'est-à-dire elles sont originalement compressées. En plus; à
cause du temps et d'allocation des ressources pendant le processus de la compression et la
décompression; il est conseillé de désactiver carrément la qualité de la compression d'image JPEG,
ou bien de choisir une valeur inférieure à 75 %.
Dans les réseaux avec un débit minime; il est conseillé de sélectionner et d'utiliser la couleur grise à
cause de la faible occupation de la bande passante et de la qualité des images offerte par cette
couleur.
En moyenne, par substitution des cas exceptionnels; une réception de données occupe 114.31 KB
dans une période de 279.73 ms, ce qui donne presque 409 KB/Seconde.
4.3.2. Transfert de fichiers
Jusqu'à la version actuelle du jrdesktop, le transfert de fichiers s'effectue sans compression de
données, ce transfert est géré par le module Admin. Plusieurs facteurs : état du disque dur
(défragmenter ou non par exemple), occupation du CPU et de la mémoire, trafic de la bande
passante…etc. peuvent influencer sur le transfert des fichiers.

70
Le présent test est fait sur un échantillon aléatoire de fichiers et de dossiers dont 61 dossiers et 147
fichiers avec une taille totale de 110 MB et en moyenne de 767 KB par fichier (14.7 MB est la taille
du grand fichier et 332 KB est la taille du petit fichier). (Cf. Figure 4.25)
Figure 4.25 – Transfert de fichiers
Alors, en moyenne, le temps nécessaire pour l'envoie de ces fichiers est 20.2 sec avec une vitesse de
5601,4 KB/S, et 25.6 sec pour la réception avec une vitesse de 4070 KB/S.
On remarque que l'émission des données est plus rapide que la réception par le serveur, car dans le
cas d'une émission; l'Admin fait appel à une méthode distante en passant le fichier lui-même – qui
situé au niveau de l'Admin – comme paramètre, au contraire lors d'une opération de réception où
l'Admin fait appel à une autre méthode distante en passant le nom de fichier – qui situé au niveau de
l'Hôte – comme paramètre et la méthode renvoie ensuite ce fichier comme valeur de retour.
4.4. Comparaison du jrdesktop avec d’autres logiciels :
On va évaluer notre projet selon une comparaison avec d’autres logiciels de bureau distant
développés en Java par les deux tableaux suivants, un tableau pour une comparaison générale et
l’autre pour une comparaison détaillée.
La comparaison est faite par la consultation des guides d'utilisation, du code source et même par le
teste et l'application directes de ces logiciels.
CopyRect est un algorithme intéressant qui permet de diviser l'écran en morceaux, et de transférer les
rectangles changés seulement à la place de l'écran toute entier.
L'option enregistrement est le module qui permet de garder une copie de la session de visualisation
(sous forme d'une vidéo par exemple) pour la consulter ultérieurement.
Selon la première comparaison (Cf. Tableau 4.7) on peut classer notre logiciel jrdesktop (dernier
ligne) parmi les premiers, car il permet toutes les fonctionnalités citées dans le tableau
excepte l'implémentation d’un protocole propriétaire à la place de l’utilisation des protocoles
standards tel que RDP et VNC, ainsi il n’y a pas de client web.

71
Selon le deuxième tableau on remarque que jrdesktop a plus de fonctionnalités que les autres
logiciels, donc on peut le classer en premier grâce à son utilisation de cryptage, de compression de
données, transfert de fichiers et presse-papiers. Mais en contrepartie il y a le manque de chat, d’un
relai, de tunnel http et de proxy.
Parmi les autres projets, Jxta Remote Desktop semble le plus intéressent, car il est open source et
supporte plusieurs fonctionnalités, surtout au coté de la communication (la présence d'un relai, un
tunnel http et peut être un proxy).

72
:disponible×:nondisponible?:nondéterminée?:nonfonctionnelleOOS:OpenSourceSoftwareProp.:Proprétaire
Tableau4.7–Comparaisongénérale

73
:disponible×:nondisponible?:nondéterminée?:nonfonctionnelle
Tableau4.8–Comparaisondétaillés

74
5. jrdesktop sur le net
Dès le commencement du projet, notre but était de développer une application open source destinée à
la communauté libre, car une application open source à l'avantage de partager le code source et
d'encourager d'autres personnes (de monde entier) à participer dans le projet par leurs suggestions et
leurs idées, par signalisation des erreurs et des anomalies et par contribution directe dans le
développement. Plusieurs e-mails posant des questions, remarquant des bugs et même proposant des
améliorations on été reçus.
La disponibilité des cours, tutoriaux, forums de discussion et même des applications de bureau
distant (open source) sur le web ont beaucoups aidés dans la phase de développement.
À la date du 09 mars 2008, le projet était accepté pour être hébergé aux serveurs de SourceForge.net,
le portail des projets libres. A l'heure actuelle (16-06-2008); le nombre total de téléchargement de
jrdesktop est à l'environ de 3 000 téléchargements avec une moyenne de 33 téléchargements et 50
visites par jour.
jrdesktop est publié (essentiellement) chez cinq (05) différentes sources: Sourceforge, Google code,
Wikipedia, ohloh et FreeBSD.
5.1. Site web du Projet jrdesktop sur sourceForge.net
Figure 4.26 – jrdesktop sur SourceForge

75
Ce site (Cf. Figure 4.26) est automatiquement crée par sourceForge.net, il offre des services
étonnants aux développeurs, tel que des informations sur le projet, actualités, statistiques, forums de
discussion, espace de téléchargements, exploration du code par CVS ou SVN et captures d'écran …
etc.
Parmi les différents statistiques fournis, voici le schéma ci-dessous (Cf. Figure 4.27) généré le 15
juin 2008 indiquant l'historique du téléchargement de projet (nombre de téléchargements/mois) avec
la taille des données servies (MB/mois), où on observe e le nombre 1500 téléchargements qui à été
atteindre le mois de mai 2008 avec plus de 150 MB des données servies (taille totale des fichiers
fournis).
Figure 4.27 – Statistiques sur les téléchargements de jrdesktop
Lien d'accès : http://sourceforge.net/projects/jrdesktop/
Date d'introduction du site : 09-03-2008.
5.2. Site web officiel du projet
Ce sont des simples pages web crées pour fournir des informations de base concernant l'application:
définition, avantages, guide par des lignes de commande et téléchargement (Cf. Figure 4.28).
Le site est publié le 01 mai 2008. A l'heure actuelle, le site a reçu plus de 2 290 visites dont 2 000
visiteurs presque, avec 7 030 pages vues, en moyenne de 3.12 pages vues/visite. Les visiteurs
viennent de 83 différents pays dont 49 visites de l’Algérie, 707 visites des Etats-Unis d’Amérique.
Les principales sources d'accès au site sont (Cf. Tableau 4.9).
Source d'accès Nombre de visites Pourcentage
wikipedia.org 1 326 57.85 %
Direct (anonyme) 326 14.22 %
sourceforge.net 250 10.91 %
open-open.com 131 05.72 %
Autres 259 11.30 %
Tableau 4.9 – Statistiques sur les sources d'accès au site officiel du jrdesktop

76
On voit que plus de 57 % des visiteurs viennent de l'encyclopédie wikipedia. L’origine de cette
statistique est le « Google Analytics », un service d’analyse de sites web gratuit proposé par le géant
américain de l'informatique Google. Il a fourni pour notre site un rapport détaillé sur l'accès au site
(voir l'annexe: Dashboard Report).
Figure 4.28 – Site web officiel du projet
Lien d'accès : http://jrdesktop.sourceforge.net/
5.3. jrdesktop sur wikipedia
Wikipedia est une encyclopédie libre, universelle et multilingues, l'introduction du jrdesktop à
wikipedia a beaucoup aidé le projet de se familiarisé au monde entier. Plus de 50% des visiteurs du
site web officiel du projet viennent du wikipedia.
La page du projet contient une petite introduction, avec des captures d'écran, ainsi des liens vers
d'autres sujets connexes (Cf. Figure 4.29).

77
Figure 4.29 – jrdesktop sur wikipedia.org
Liens d'accès :
· http://en.wikipedia.org/wiki/Java_Remote_Desktop
· http://en.wikipedia.org/wiki/Jrdesktop
5.4. jrdesktop sur Google Code Hosting Project
Hosting Project est un service gratuit d'hébergement de projets open source sur la plate forme Google
code, jrdesktop est présenté d'une façon simplifiée avec possibilité de téléchargement, d'autres
services sont également disponible tel que l'exploration du code par SVN, système de gestion de
contenu (wiki) ou CMS (Content Management Systems ou CMS), gestion des bugs (issues) …etc.
Liens d'accès :
· http://jrdesktop.googlecode.com/
· http://code.google.com/p/jrdesktop/

78
5.5. jrdesktop sur Ohloh
Ohloh est un autre portail de projet open source qui fournit divers services destinés aux développeurs,
tel que l'analyse du code, calcul des coûts de projet, sondages, statistiques, actualités …etc.
Liens d'accès : http://www.ohloh.net/projects/jrdesktop/
5.6. jrdesktop sur FreeBSD
Jrdesktop est porté sur FreeBSD, ce système d'exploitation utilise un système de management de
paquets appelé "FreeBSD Port collection", où un port est une application patchée (mise à jour avec
possibles correction des bugs), attachée à des makefiles (scripts pour construction automatique) pour
produire une façon simple d'installation ou de création des paquets binaires [4].
Liens d'accès :
· http://www.freshports.org/net/jrdesktop/
· http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/jrdesktop/
6. conclusion
Dans ce chapitre, nous avons vue que notre application Java Remote Desktop est multiplateforme
grâce à la machine virtuelle, Ainsi, elle est sécurisée car elle utilise le protocole de cryptage SSL très
utilisé pour améliorer la sécurité des échanges de données.
On peut dire que jrdesktop est une console d’administration permettant la visualisation et le contrôle
d’ordinateur distant. En effet, grâce au logiciel jrdesktop la personne ayant la main mise sur la
console d’administration pourra gérer son parc informatique comme bon lui semble. Elle pourra avoir
une vision d’ensemble des postes Hôte en fonctionnement. Elle lui sera possible de sélectionner un
ordinateur pour pouvoir le visionner en plein écran, ou prendre le contrôle.
Notre projet jrdesktop vient d’être classé parmi les plus grands logiciels de bureau à distance qui
existent en raison des avantages qu’il offre.

Conclusion Générale
79
« Les braves gens ne savent pas ce qu’il en coûte de temps et
de peine pour apprendre à lire. J’ai travaillé à cela quatre
vingt ans et je ne peux pas dire encore que j’y suis arrivé »
Geothe
Nous pouvons affirmer à travers ce mémoire que notre but a été atteint : le lecteur est assez
enrichi de tous ce qui concerne le contrôle à distance à travers les applications sous le nom de bureau
à distance, un domaine plus pratique et important dans la vie pratique des gens utilisant le réseau
local ou mondial, et surtout pour les entreprises travaillant essentiellement dans la maintenance, le
dépannage et la téléintervention. En effet, Le bureau distant peut aider les administrateurs réseaux,
PDGs ou responsables informatiques de gérer les différents ordinateurs de leurs entreprises depuis
une seule machine. Il pourrait notamment être utilisé par les entreprises possédant un parc
informatique. C’est aujourd’hui que les entreprises doivent investir dans ce domaine si elles
veulent y jouer un rôle majeur.
Au cours de la réalisation de notre travail, nous avons choisi d’utiliser comme langage de
programmation le langage Java, ainsi que des outils et des technologies assez importants et que nous
sembles un bon choix de fait les intérêts qu’ils offrent à savoir : la rapidité, la facilité de la mise en
œuvre, la robustesse et la sécurité.
Notre application développée « jrdesktop » est un outil très puissant, facile à utiliser et qui est
capable de fournir à travers ces fonctionnalités intéressantes, un grand nombre de manipulations à
distance. Elle ne requiert pas d'être un gourou de l'ordinateur pour l’utiliser afin d’atteindre notre
objectif.
Il suffit juste d’accéder au site officiel jrdesktop.sourceforge.net, de le télécharger en
quelques secondes, et de le faire exécuter. Ce logiciel ne nécessite aucun moyen supplémentaire,
excepte le fait que l’ordinateur soit équipé d’une machine virtuelle Java (JVM), si ce n’est pas le cas,
il suffit d’aller au site de Sun afin de télécharger le JRE et l’installer.
Le point fort de notre application réside dans le fait qu’elle est multiplateforme puisqu'elle
fonctionne, grâce à la machine virtuelle Java, sur divers systèmes d'exploitation tel que Linux, MAC
OS et dont la plupart des versions Windows VISTA, XP (en général toutes les versions NT et win9x)
sont incluses, ce qui ne pose aucun problème pour les réseaux Windows, Unix ou autre, notamment
les réseaux hétérogènes.

80
Notre projet dénommé jrdesktop vient d’être classé. En effet il offre avec son support toutes les
fonctionnalités listées dans le tableau comparatif 1.1 de 1er
chapitre, excepte le support sonore.
Enfin, nous espérons que ce travail pourra contribuer à servir des futurs travaux en vue d’élargir
le domaine d’application. Ces perspectives peuvent être exprimées ainsi :
· Réécriture du code en utilisant les sockets pour la communication à la place du RMI. En effet,
les sockets sont préférables pour le transfert de grandes quantités d'informations et dans les
applications en temps réel.
· Implémentation de l'algorithme CopyRect, qui permet de diviser l'écran en petits morceaux et de
transférer seulement les cadres changés. En effet, actuellement jrdesktop peut transférer
plusieurs captures d'écran par seconde, mais l'écran peut être stable pendant plus d'une minute,
alors que tout ce trafic est inutile.
· Ajout de la documentation API du projet et des guides de développement et d'utilisation (surtout
en anglais), cela encourage d'autres développeurs à participer et aussi à enrichir le projet.
· Mise en œuvre d'un visualisateur web qui permet de contrôler un PC distant en utilisant un
navigateur Internet, ce module est très pratique dans les cas où l'utilisateur n'a pas le droit de
télécharger et/ou d'installer et/ou d'utiliser des logiciels non autorisés.
· Implémentation de la fonction inversible qui permet à un PC d'être contrôlé en donnant l'adresse
IP du visualisateur. Ce cas est très pratique lorsque le PC contrôlé n'est pas atteignable (PC
derrière un pare-feu, routeur/NAT ou un proxy). Dans ce cas; le serveur est le visualisateur
(module Admin) et le client est le module hôte.
· Ajout des fonctions de détection du débit (taille de la bande passante) pour l'adaptation
automatique des paramètres d'application aux différents Réseaux (LAN, MAN ou Internet).
· Ajout des fonctionnalités supplémentaires au module Hôte pour la gestion des utilisateurs
Admin tel que les droits d'accès, filtrage des plages IP pour éliminer (ou minimiser) les accès
non souhaités.
· Implémentation d'un gestionnaire de fichiers (sous forme de deux explorateurs local et distant)
qui permet de gérer mieux le transfert et la synchronisation des données entre les 2 PCs.
· Inclusion d'un chat (écrit et/ou vocale), cela facilite beaucoup la communication entre les
utilisateurs des 2 PC, surtout si jrdesktop est utilisé pour une opération de maintenance ou de
collaboration en ligne.
· Ajout de la visualisation multiple qui permet d'observer plusieurs PCs en même temps et de
lancer le contrôle d'un PC par un clic sur son cadre. Cette fenêtre peut être de type Multiple
Document Interface (MDI) comme la fenêtre de Word de Microsoft qui permet d'ouvrir et de
travailler avec plusieurs documents en même temps).

Glossaire
i
GLOSSAIRE
ADSL: Asymmetrical Digital Subscriber Line. Technologie qui permet d'atteindre, sur des lignes
téléphoniques traditionnelles, des hauts débits de transmission numérique qui varient en fonction
de la distance et qui sont dits « asymétriques », parce qu'il n'y a pas d'équivalence entre la vitesse
de la transmission réseau-abonné et celle de la transmission abonné-réseau.
AES : Advanced Encryption Standard. Algorithme de chiffrement commandé et utilisé par le
gouvernement étasunien (entre autres).
AIP : Adaptive Internet Protocol. Un protocole multi-canal qui permet à un utilisateur surtout un
vaste éventail de systèmes clients de se connecter à des applications s'exécutant sur plusieurs
plates-formes.
API : Application Programming Interface. Interface de programmation d'applications, contenant
un ensemble de fonctions courantes de bas niveau, bien documentées, permettant de programmer
des applications de « Haut Niveau ».
Certificat numérique : document électronique identifiant une entité (personne physique ou
morale, équipement...). Il est formé par des informations pertinentes à son utilisation (nom,
adresse, société, numéro de téléphone), la clef publique de l'entité, le tout est signé par un tiers de
confiance (autorité de certification).
FAI : désigne une société vendant (ou revendant) de la bande passante connectée plus ou moins
directement à l'Internet.
Firewall : protéger le réseau interne des accès non autorisés à partir de l'Internet. Durant un
échange de données, un filtrage inspecte en permanence chaque paquet, bloquant rapidement
toute tentative de communication indésirable.
Helpdesk : ou bureau d'assistance, est un service de support technique d'entreprise permettant de
procéder à la gestion des incidents informatiques.
ICA : Independent Computing Architecture. Protocole de niveau 7 OSI (Open System Interconnect)
permettant de réaliser un déport d'affichage sous Windows.
Interopérabilité : capacité qu'ont deux systèmes de se comprendre l'un l'autre et de fonctionner
en synergie. Contraire : incompatibilité.
GPL : General Public License. Le statut juridique des logiciels distribués « librement », à
l'origine utilisé pour le projet GNU de la FSF. Ça commence comme ça : « Everyone is permitted
to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Glossaire
ii
JDK : Java Development Kit. Environnement de développement de Sun permettant de produire
du code Java et servant de référence. La version 1.1 est sortie en 1997.
JRE: Java Runtime Environment. Environnement d'exécution des applications Java.
JVM: Java Virtual Machine. Interpréteur du code Java qui permet l'exécution du programme, sur
une machine en particulier (le code Java restant le même d'un système à un autre).
Loopback : permet de voir et de contrôler l'ordinateur local au même comme s'il s'agissait d'une
machine distante (l'adresse IP correspondante est 127.0.0.1). Ce type de connexion n'est pas
pratique, il sert à faire des tests seulement.
NAT : Network Address Translation. Méthode de traduction d'adresse IP non routables en
adresses routables et réciproquement, et qui permet de connecter de nombreuses machines au
réseau en n'utilisant qu'un minimum d'adresses officielles. Surtout utilisé dans les routeurs et les
firewalls.
OS : Operating System. Système d'exploitation, équivalent français du sigle : SE. On retrouve ce
sigle dans pas mal de noms propres, comme OS/2, OS/9, OS/360. OSes est le pluriel d'OS.
OSS : Open Source Software. Logiciel libre.
Pare-feu : ou firewall en anglais est un moyen de bloquer les demandes non sollicitées, Il
constitue un rempart de défense contre les personnes non autorisées qui essaient d'accéder à votre
ordinateur depuis l'extérieur et contre les applications installées sur le système et qui veulent
communiquer à l'extérieur. Le pare-feu comme celle de Windows peut-être être désactivé, ainsi il
est géré par l’utilisateur, il demande l'autorisation de bloquer ou de débloquer certaines demandes
de connexion dans les deux sens.
Propriétaire : caractérise les systèmes qui appartiennent à une personne (physique ou morale) en
particulier. Ces systèmes ne sont pas des standards à l'origine (mais ils peuvent le devenir) et ne
sont pas compatibles avec les systèmes comparables de la concurrence. Contraire : libre.
Protocole: une spécification de plusieurs règles et d'ensemble de contraintes permettant d'établir
une communication entre deux entités, il s'assure que les données qui ont été envoyées, ont bien
été reçues (et en bon état). Pour l'accès à distance il existe des protocoles spécifiques notamment
les plus appréciés: RFB et RDP.
Proxy : serveur recevant des requêtes qui ne lui sont pas destinées et qui les transmet aux autres
serveurs. Cela permet à quelqu'un qui se trouve derrière un firewall d'avoir accès à des ressources
sans prendre de risques. Le Proxy sait aussi être intelligent : quand il reçoit une requête, il stocke
le résultat. Si la même requête lui est à nouveau envoyée, il vérifie que le résultat n'a pas été
modifié et renvoie le résultat qu'il a « déjà sous la main » à celui qui a fait la requête (fonctionnant
ainsi comme un cache).
RDP: Remote Desktop Protocol. Un protocole qui permet à un utilisateur de se connecter sur un
ordinateur faisant tourner Microsoft Terminal Services. Des clients existent pour la quasi-totalité

Glossaire
iii
des versions de Windows, et pour d'autres systèmes d'exploitation, comme Linux. Le serveur
écoute par défaut sur le port TCP 3389.
RFB : Remote Frame Buffer. Un protocole simple pour l'accès à distance aux interfaces
graphiques des utilisateurs, utilisé dans Virtual Network Computing (VNC) et de ses dérivés.
RFB utilise le port 5900 UDP/TCP (VNC server).
Sessions Multiples: de multiples connexions simultanées. Avec cette fonctionnalité,
l'administrateur réseau peut assurer efficacement le contrôle à distance des PCs différents
simultanément. En outre, deux ou plusieurs administrateurs peuvent contrôler un ordinateur
distant à la fois et chacun avec leurs propres fenêtres.
RMI-IIOP : Internet Inter-Orb Protocol. Protocole normalisé par l'OMG (Object Management
Group) et utilisé dans l'architecture CORBA (Common Object Request Broker Achitecture).
Routeur : élément intermédiaire dans un réseau informatique dont son rôle est essentiellement la
définition de la table de routage et la redirection des informations. Un routeur est aussi disponible
sous forme d’un logiciel informatique.
Sessions Multiples: de multiples connexions simultanées. Avec cette fonctionnalité,
l'administrateur réseau peut assurer efficacement le contrôle à distance des PCs différents
simultanément. En outre, deux ou plusieurs administrateurs peuvent contrôler un ordinateur
distant à la fois et chacun avec leurs propres fenêtres.
Snapshot : copie de la mémoire vidéo, de la mémoire principale ou d’une base de données à un
moment déterminé.
TCP/IP : Transmission Control Protocol / Internet Protocol. Les deux protocoles de
communication qui forment les fondements de l'Internet.
VNC : un logiciel ouvert pour se connecter à un ordinateur distant. Il permet de transmettre les
saisies au clavier ainsi que les clics de souris d'un ordinateur à l'autre, à travers un réseau
informatique. Il existe d'autres alternatifs tels que RealVNC, EchoVNC, UltraVNC …etc.
VoIP : Voice Over IP. Principe consistant à faire passer des communications téléphoniques
numérisées dans des paquets IP. C'est le téléphone sur l'Internet, donc.

Annexe A: Tableau de bord du site web du jrdesktop
Annexe B: Description du diagramme de classe

jrdesktop.sourceforge.net/
Tableau de bord
1 mai 2008 - 15 juin 2008
Comparaison avec : Site
100
200
100
200
5 mai 2008 12 mai 2008 19 mai 2008 26 mai 2008 2 juin 2008 9 juin 2008
Visites
Fréquentation du site
2 292 Visites
7 174 Pages vues
3,13 Pages par visite
27,36 % Taux de rebond
00:02:33 Temps moyen sur le site
87,00 % Nouvelles visites (en %)
Vue d'ensemble des visiteurs
100
200
100
200
Visiteurs
Visiteurs
1 994
Vue d'ensemble des sources de trafic
Sites référents
1 951 (85,12 %)
Accès directs
326 (14,22 %)
Moteurs de recherche
15 (0,65 %)
Synthèse géographique world
Visites
1 707
Vue d'ensemble du contenu
Pages Pages vues Pages vues
(en %)
/ 2 937 40,94 %
/download.php 1 580 22,02 %
/screenshots.php 1 522 21,22 %
/start.php 762 10,62 %
/index.php 307 4,28 %
1 Google Analytics

Vue d'ensemble des visiteurs
1 mai 2008 - 15 juin 2008
100
200
100
200
Visiteurs
1 994 internautes ont visité ce site.
2 292 Visites
1 994 Visiteurs uniques absolus
7 174 Pages vues
3,13 Nombre moyen de pages vues
00:02:33 Temps passé sur le site
87,17 % Nouvelles visites
Profil technique
Navigateur Visites Visites (en %)
Firefox 1 406 61,34 %
Internet Explorer 647 28,23 %
Opera 102 4,45 %
Safari 74 3,23 %
Mozilla 36 1,57 %
Vitesse de connexion Visites Visites (en %)
Unknown 852 37,17 %
DSL 664 28,97 %
Cable 445 19,42 %
T1 236 10,30 %
Dialup 87 3,80 %
2 Google Analytics

Vue d'ensemble des sources de trafic
1 mai 2008 - 15 juin 2008
100
200
100
200
Visites
L'ensemble des sources de trafic a généré 2 292 visites au total.
14,22 % Accès directs
85,12 % Sites référents
0,65 % Moteurs de recherche
Sites référents
1 951 (85,12 %)
Accès directs
326 (14,22 %)
Moteurs de recherche
15 (0,65 %)
Principales sources de trafic
Sources Visites Visites (en %)
en.wikipedia.org (referral) 1 326 57,85 %
(direct) ((none)) 326 14,22 %
sourceforge.net (referral) 250 10,91 %
open-open.com (referral) 131 5,72 %
freshports.org (referral) 94 4,10 %
Mots clés Visites Visites (en %)
jrdesktop 7 46,67 %
jrdesktop sourceforge 5 33,33 %
"jrdesktop" 1 6,67 %
remote desktop 1 6,67 %
web remote desktop 1 6,67 %
3 Google Analytics

Synthèse géographique
1 mai 2008 - 15 juin 2008
Visites
1 707
2 292 visites, provenant de 83 pays/territoires.
Fréquentation du site
Visites
2 292
Total du site (en %) :
100,00 %
Pages par visite
3,13
Moyenne du site :
3,13 (0,00 %)
Temps moyen sur le
site
00:02:33
Moyenne du site :
00:02:33 (0,00 %)
Nouvelles visites (en
%)
87,13 %
Moyenne du site :
87,00 % (0,15 %)
Taux de rebond
27,36 %
Moyenne du site :
27,36 % (0,00 %)
Pays/Territoire Visites Pages par
visite
Temps moyen
sur le site
Nouvelles
visites (en %)
Taux de
rebond
United States 707 3,35 00:02:16 90,10 % 25,18 %
China 163 2,66 00:02:18 88,96 % 21,47 %
United Kingdom 138 3,05 00:02:24 86,96 % 31,16 %
Germany 133 3,14 00:02:43 85,71 % 32,33 %
Canada 111 3,05 00:01:50 90,99 % 37,84 %
Netherlands 59 3,49 00:04:13 79,66 % 20,34 %
Australia 54 3,09 00:03:42 92,59 % 29,63 %
Italy 53 3,08 00:03:19 86,79 % 28,30 %
India 50 3,18 00:01:58 92,00 % 24,00 %
Algeria 49 3,59 00:06:31 40,82 % 44,90 %
De 1 à 10 sur 83
4 Google Analytics

Vue d'ensemble du contenu
1 mai 2008 - 15 juin 2008
200
400
200
400
Pages vues
Les pages de ce site ont été consultées 7 174 fois au total.
7 174 Pages vues
5 074 Consultations uniques
Pages les plus consultées
Pages Pages vues Pages vues (en %)
/ 2 937 40,94 %
/download.php 1 580 22,02 %
/screenshots.php 1 522 21,22 %
/start.php 762 10,62 %
/index.php 307 4,28 %
5 Google Analytics

Description du diagramme de classe
Annexe B i

Le projet est organisé en 10 paquetages imbriqués reliées entre aux; chaque paquetage est peut être
constitué d'un ensemble de sous paquetages et/ou des classe (ou des fichiers en générale).
Paquet principal du l'application
Fenêtre d'à-propos;
Fichier de la configuration;
Classe d'informations sur la connexion;
Classe des propriétés d'hôte;
Classe de gestion des permissions;
Classe d'icône de la barre des taches;
Clé de la sécurité;
Classe principal;
Fenêtre principale;
Clé de la sécurité.
Le dossier d'images
Paquet principal du Server
Fenêtre des connexions actives;
Fichier de la configuration;
Fenêtre de la configuration;
Classe robot.
Interface RMI du server
Classe du serveur multihome;
Classe du serveur jrdesktop;
Classe d'implémentation du serveur;
Classe d'interface du serveur.
Paquet d'utilités
Classe gestionnaire du presse-papiers;
Classe utilitaire des fichiers;
Classe utilitaire d'images;
Classe utilitaire d'adressage;
Classe utilitaire de compression;
Paquet principal du Viewer
Fichier de configuration;
Boite du dialogue de la connexion;
Classe d'enregistrement;
Classe d'afficheur d'écran;
Classe gestionnaire des données;
Fenêtre principale.
Paquet de gestion de fichiers de Viewer
Classe Gestionnaire de fichiers;
Fenêtre de la transmission des fichiers;
Auditeur de la cible des fichiers
Interface RMI du Viewer
Classe visualisateur du jrdesktop
La structure du code source de jrdesktop

Annexe B ii

1. Paquetage jrdesktop
C'est le paquetage principale du notre application, il contient des sous paquetages, des classes, des
images et d'autres fichiers divers. Ce paquetage inclut aussi la fenêtre principale, l'icône de la barre
des tâches, et les classes partagées entre les modules Server et Viewer.
1.1. Classe main (jrdesktop.main)
Classe principale du notre application
1.2.Classe Config (jrdesktop.Config)
Gestion de la configuration.

1.3.Classe HostProperties (jrdesktop.HostProperties)
Englobe les propriétés de l'ordinateur distant.

Annexe B iii

1.4.Classe mainFrame (jrdesktop.mainFrame)
Fenêtre principale du notre application.

Annexe B iv

1.5.Classe SysTray (jrdesktop.SysTray)
Gestion de l'icône dans la barre des tâches.

1.6.Classe ConnectionInfos (jrdesktop.ConnectionInfos)
Statistiques sur la connexion.

Annexe B v

1.7.Classe SecurityMng (jrdesktop.SecurityMng)
Gestion des permissions.

1.8.Classe AboutGUI (jrdesktop.AboutGUI)
Fenêtre d'à-propos.

2. Paqeutage images (jrdesktop.images)
Ce paquet contient tous les images (icones) utilisées dans les fenêtres du jrdesktop, comme les
buttons, logo d'application et l'icone dans la barre des tâches.

Annexe B vi

3. Paqeutage utilities (jrdesktop.utilities)
Paquet utilitaire contient divers méthodes utiles pour notre projet, tel que le traitement d'images,
outils de compression, adressage, gestion des fichiers et du presse-papiers.
Ce paquetage est – en général - indépendant aux autres paquetages du jrdesktop, il peut facilement
servir d'autre application Java.
3.1.Classe ZipUtility (jrdesktop.utilities.ZipUtility)
Utilitaires de la compression.

3.2.Classe InetAdreUtility (jrdesktop.utilities.InetAdreUtility)
Utilitaires d'adressage.

3.3.Classe ClipbrdUtility (jrdesktop.utilities.ClipbrdUtility)
Gestionnaire du presse-papiers

Annexe B vii

3.4.Classe FileUtility (jrdesktop.utilities.FileUtility)
Gestionnaire de fichiers.

3.5.Classe ImageUtility (jrdesktop.utilities.ImageUtility)
Traitement d'images.
4. Paqeutage server (jrdesktop.server)
Ce paquetage contient tous les classes et les sous paquetage du serveur jrdesktop. Dont main est le
paquetage principal et rmi est le paquetage de la communication.
5. Paqeutage main (jrdesktop.server.main)
Paquetage de base du serveur jrdesktop.
5.1. Classe ActiveConnectionsGUI (jrdesktop.server.main.ActiveConnectionsGUI)
Gestion des visualisateurs
connectées.

Annexe B viii

5.2. Classe ConfigGUI (jrdesktop.server.main.ConfigGUI)
Fenêtre de la configuration

5.3. Classe Config (jrdesktop.server.main.Config)
Gestion de la configuration

Annexe B ix

5.4. Classe robot (jrdesktop.server.main.robot)
Classe robot.

6. Paqeutage rmi (jrdesktop.server.rmi)
Paquetage de responsable de la communication.
6.1. Classe ServerInterface (jrdesktop.server.rmi.ServerInterface)
Classe d'interface.

6.2. Classe ServerInterface (jrdesktop.server.rmi.ServerImpl)
Classe
d'implémentation du
serveur.

Annexe B x

6.3. Classe Server (jrdesktop.server.rmi.Server)
Serveur
jrdesktop.

Annexe B xi

6.4. Classe MultihomeRMIClientSocketFactory
(jrdesktop.server.rmi.MultihomeRMIClientSocketFactory)
Serveur multihome.

7. Paqeutage viewer (jrdesktop.viewer)
Ce paquetage contient tous les classes et les sous paquetage du visualisateur jrdesktop. Dont main est
le paquetage principal et rmi est le paquetage de la communication.
8. Paqeutage main (jrdesktop.viewer.main)
Paquetage de base du visualisateur jrdesktop.
8.1. Classe ViewerData (jrdesktop.viewer.main.ViewerData)
Gestionnaire des
données.

Annexe B xii

8.2. Classe ConnectionDialog (jrdesktop.viewer.main.ConnectionDialog)
Boite du dialogue de
la connexion.

Annexe B xiii

8.3. Classe ScreenPlayer (jrdesktop.viewer.main.ScreenPlayer)
Afficheur d'écran.

Annexe B xiv

8.4.ClasseViewerGUI(jrdesktop.viewer.main.ViewerGUI)Fenêtredelavisualisation.

Annexe B xv

8.5. Classe Config (jrdesktop.viewer.main.Config)
Gestion de la
configuration.

8.6. Classe recorder (jrdesktop.viewer.main.recorder)
Classe
d'enregistrement.

Annexe B xvi

9. Paquetage FileMng (jrdesktop.viewer.main.FileMng)
9.1. Classe FileTransGUI (jrdesktop.viewer.main.FileMng.FileTransGUI)
Fenêtre de la
transmission des
fichiers.

Annexe B xvii

9.2. Classe FileManager (jrdesktop.viewer.main.FileMng.FileManager)
Gestionnaire de
fichiers

9.3. Classe FilesDropTargetListener
(jrdesktop.viewer.main.FileMng.FilesDropTargetListener)
Auditeur de la
cible des fichiers.

10. Paquetage Viewer.rmi (jrdesktop.viewer.rmi)
Paquetage de responsable de la communication avec le serveur RMI.
10.1. Classe Viewer
(jrdesktop.viewer.rmi.Viewer)

Annexe B xviii

visualisateur du
jrdesktop.

Bibliographie
i
BIBLIOGRAPHIE
[1] Fadili Ousmane. " Projet: PcAnywhere et Le contrôle à distance ". Faculté des sciences –
Nîmes, Enseignant GEII, Département Génie électrique et Informatique Industrielle, session
2005.
http://www.geii.iut-nimes.fr/fl/webmaster/
[2] Multimédia : Technologie. " Les différents types de connexion à l'Internet ". Article, 28
Novembre 2000.
http://multimedia.sdv.fr/article/art_aff_2006.php?id=241&rub=4&ssrub=43
[3] Les guides de NET. "Internet & World Wide Web: Perspectives & Applications pour
l'Entreprise". Octobre 1996.
http://jcpatat.nerim.net/net/WWWent.html
[4] Wikipedia, Encyclopédie libre, collaborative en ligne, universelle et multilingue, 2008:
http://www.wikipedia.org/
[5] Irène Charon. " Le langage Java concepts et pratique ". Ouvrage, Éditions Hermès science,
2éme
édition, paris, février 2003.
[6] Emmanuel Remy. " Généralités sur java ", 2001.
http://pagesperso-orange.fr/emmanuel.remy/Java/Generalites/Generalites.htm
[7] Le site Web de Mâamoun BERNICHI. " Tutoriels, Java, RMI ", Université Paris XII.
http://www.bernichi.com/cms/java/rmi.html
[8] Laboratoire SUPINFO. " RMI - Application distribuée - Essentiels de cours Java ".
http://www.labo-sun.com/
[9] Comment ça Marche.
http://www.commentcamarche.net/
[10] Security Focus. "Apache 2 with SSL/TLS: Step-by-Step", Janvier 2005.
http://www.securityfocus.com/infocus/1818
[11] JDNet Développeurs. " TUTORIELS, SSL en Java avec JSSE ", Aout 2001.
http://www.journaldunet.com/developpeur/tutoriel/jav/010820jav_javassl.shtml
[12] FAQ NetBeans - Club d'entraide des développeurs francophones. "Découvrir NetBeans", 2008.
http://java.developpez.com/faq/netbeans/
[13] Le site officiel de NetBeans, le coin des francophones. " NetBeans 6.0 ", décembre 2007.
http://fr.netbeans.org/

Bibliographie
ii
[14] Le grand Dictionnaire terminologique. Logiciel, Edition 2001.
[15] Sun. "The Java Tutorials".Mise à jour 10 Novembre 2006.
http://java.sun.com/docs/books/tutorial/
[16] Sun, "Online Java Forums".
http:forums.java.sun.com/
[17] UML en français, Cours UML
http://uml.free.fr/
[18] Pascal Roques. "UML par la pratique". Ouvrage, Édition Eyrolles, 2éme
, 2003.
[19] Elliotte Rusty Harold. "Java Network Programming". Ouvrage, O'Reilly, 3éme
Edition, 2004.
[20] Hafid Bourzoufi, Didier Donsez. "RMI Remote Method Invocation". Université de
valenciennes Institut des Sciences et Techniques de Valenciennes,2000.
[21] Jean Michel Doudoux." Développons en Java ", version 0.90, 2006.
http://www.jmdoudoux.fr/java/
[22] Michael Lerner Productions. Apprentissage des Bases : à propos des modems (LEARN THE
NET : à propos des modems), Article, mise à jour 10 Décembre 2000.
http://www.learnthenet.com/French/html/05modems.htm

Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop

Contenu connexe

Tendances

Similaire à Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop

Plus de Bachir Benyammi

Dernier

Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA - jrdesktop