Projet Java : Partage d'Écran et Contrôle à Distance
Concurrent
1. La conception
1.1-Diagramme de Cas d'Utilisation:
1. L'Utilisateur Contrôleur (celui qui prend le contrôle) :
Envoyer Événements Clavier/Souris : Il peut utiliser son clavier et sa souris
pour agir sur l'ordinateur distant.
Établir Connexion : Il peut se connecter à l'ordinateur distant.
o Authentifier Hôte (extends Établir Connexion) : Cela veut dire que
pour "Établir Connexion", il peut être nécessaire de "Authentifier Hôte"
(par exemple, entrer un mot de passe). Ce n'est pas toujours obligatoire,
mais c'est une option qui étend la connexion.
Afficher Écran Distant : Il peut voir ce qui se passe sur l'écran de l'ordinateur
distant.
Déconnecter : Il peut arrêter la connexion.
2. L'Utilisateur Hôte (celui dont l'ordinateur est contrôlé) :
Exécuter Événements Locaux : Son ordinateur exécute les actions (clics,
touches) envoyées par le contrôleur.
Démarrer Serveur : Il peut lancer le programme qui permet le contrôle à
distance sur son ordinateur.
Arrêter Serveur : Il peut arrêter ce programme.
Diffuser Écran : Son ordinateur envoie son écran au contrôleur.
1.2-Le diagramme de classe :
L’application est composée de deux parties principales :
1. Application Serveur (Hôte) : l'ordinateur qui partage son écran.
2. Application Client (Contrôleur) : l'ordinateur qui voit l'écran et contrôle à
distance.
🔹 Serveur (Hôte) :
Capture l’écran (ScreenCapturer)
Envoie les images au client
Reçoit les actions clavier/souris et les exécute (ControlExecutor)
🔹 Client (Contrôleur) :
Reçoit et affiche l’écran (ScreenReceiver)
Envoie les actions de contrôle (InputSender)
🔹 Communication :
Utilise des files d’attente (BlockingQueue)
Échange via des flux Java (ObjectInputStream / ObjectOutputStream)
Gère images compressées et événements clavier/souris
1.2-Le diagramme de composants:
L'ordinateur client a une application qui a besoin de trois choses pour fonctionner :
IRemoteScreenStream : Pour recevoir l'écran à distance.
IControlSender : Pour envoyer des commandes (clics de souris, touches clavier).
IRemoteConnection : Pour établir la connexion.
L'ordinateur serveur a une application qui fournit ces trois choses :
IRemoteScreenStream : Elle envoie l'écran au client.
IRemoteCommandReceiver : Elle reçoit les commandes du client.
IRemoteConnection : Elle gère la connexion.
2. Étude détaillée de l’existant
✅ Ce qui marche bien dans TeamViewer / AnyDesk du point de vue de la
concurrence :
Aspect Exemple concret
Multi-utilisateurs en Plusieurs personnes peuvent se connecter à une même machine
parallèle (ex. : en mode “spectateur”).
Un seul utilisateur peut contrôler la souris/clavier à la fois (évite
Contrôle exclusif
les conflits).
Les actions (clics, mouvements de souris, frappes clavier) sont
Réactivité fluide
traitées en temps réel, même avec plusieurs clients.
File d’attente ou Si plusieurs personnes demandent le contrôle, il y a un système de
priorisation priorité.
❌ Ce qui peut poser problème (points faibles liés à la programmation concurrentielle)
:
Point faible Exemple concret
Si deux clients prennent le contrôle en même temps, cela peut
❗ Accès simultané non
provoquer un conflit de threads (souris qui bouge dans tous
coordonné
les sens).
❗ Pas de file d’attente ou Si 3 clients veulent le contrôle, c’est souvent celui qui clique
synchronisation le plus vite qui gagne. Ce n’est pas juste, ni bien géré.
Si un utilisateur garde le contrôle trop longtemps, les autres
❗ Blocage ou famine
attendent indéfiniment sans système de “temps de session”.
Point faible Exemple concret
❗ Pas de gestion fine des Le traitement des actions clavier/souris n’est pas toujours
threads optimisé avec des threads dédiés pour chaque tâche.
2. Notre solution : proposer une architecture Java concurrente qui
corrige ça
Objectif principal :
Créer une application Java de partage d’écran avec contrôle à distance dans laquelle :
plusieurs clients peuvent se connecter en mode spectateur (lecture seule),
un seul client à la fois peut contrôler la machine (accès exclusif),
les accès concurrents sont gérés proprement avec des threads synchronisés.
Les fonctionnalités concurrentielles de ton application :
Fonction Détail technique
✅ Accès concurrent en Plusieurs clients peuvent voir l’écran en même temps
lecture (multiclients) (thread par client).
Un seul client peut envoyer des actions clavier/souris
✅ Contrôle exclusif
(verrou avec synchronized, Semaphore, ou Lock).
Si plusieurs clients demandent le contrôle, ils sont mis en
✅ Gestion de file d’attente
file avec priorité FIFO (queue + synchronisation).
Chaque client peut avoir un temps max de contrôle (ex. : 2
✅ Temps de contrôle limité
minutes), puis libération automatique.
Un thread pour le streaming d’écran, un autre pour le
✅ Séparation des threads
contrôle utilisateur, un autre pour la file d’attente.
Authentification basique pour chaque client (nom
✅ Sécurité d’accès simplifiée
d’utilisateur/mot de passe pour gérer qui a le droit de quoi).
Exemple de situation concrète :
Safia (client 1) se connecte → elle peut voir l’écran.
Hasnae (client 2) se connecte → il voit aussi.
Hasnae demande le contrôle → il l’obtient.
Safia demande aussi le contrôle → elle est mise en file.
Après 2 min, le contrôle passe automatiquement à Safia.
Grâce à tes mécanismes de synchronisation, tout cela est fluide, sans conflit, et sans
blocage.
