Remote Desktop

Soyez le premier à donner votre avis sur cette source.

Vue 7 903 fois - Téléchargée 2 101 fois

Description

Programme client/serveur permettant de visualiser l'écran d'un poste distant.
L'accès au serveur est sécurisé (mot de passe) et l'échange est chiffré.
Il n'y a pas de contrôle clavier/souris pour le moment, mon objectif été
de développer en priorité la partie visualisation écran.

Pour le fonctionement : le serveur récupère les dimensions de l'écran et
l'envoie au client pour qu'il initialise la fenêtre aux bonnes dimensions, il
envoie ensuite au client l'essemble des pixels de l'écran. Puis envoie sans cesse
(uniquement) les pixels qui ont changé par rapport aux captures précèdentes,
cela permet d'éviter d'envoyer à chaque fois l'ensemble des pixels de l'écran et
donc d'avoir de meilleurs performances de rafraîchissement côté client.
Pour un souci de performance j'ai également opté pour le protocole UDP qui est
plus rapide que TCP pour l'envoie des bloques de pixels.

Côté client, le programme récupère au fur et à mesure les bloques de pixels
pour les dessiner dans la fenêtre.

J'ai testé ce programme principalement sur réseau local et les performances
sont plutot satisfaisante (je n'arrive pas a faire mieux), j'ai testé que très
peu de fois sur une connexion "longue distance" et là les performances ne sont
pas top... Si vous avez des idées/conseils pour améliorer les performances de
capture/comparaison/transfert/écriture des pixels pour optimiser le
rafraichissement je suis preneur :)

Le client et le serveur utilisent Qt pour l'interface graphique, les API Win pour
la communication réseau et la capture de pixel côté serveur, OpenSSL pour le
chiffrement RSA et la bibliotheque Pthread.


MAJ 1 (30/09/2013) :

-Ajout d'une fonctionalité remote shell
-Ajout d'une fonctionalité capture d'écran
-Ajout d'une fonctionalité controle de la souris
-Possibilité de réduire la fenetre serveur dans la zone de notification

Codes Sources

A voir également

Ajouter un commentaire

Commentaires

comment on lence ;(
quelqu'un peut m'aider
Messages postés
23
Date d'inscription
samedi 19 avril 2008
Statut
Membre
Dernière intervention
1 février 2014

Effectivement mon remote desktop n'a pas de très bonne performance côté rafraîchissement, pour amélioré cela j'envois donc uniquement les pixels qui ont changé par rapport aux précédentes capture.. mais ce n'est pas suffisant.

Je sais pas si envoyer une capture entière compressé en ZIP soit la meilleur solution, il faut essayer pour voir.. Mais j'ai peur que le temps d'exécution de
l'algo de compression ralentisse les perf de rafraîchissement (compression côté serveur et décompression côté client).
De plus, le format bitmap est a proscrire car trop volumineux, il faut donc enregistrer en jpg et donc encore un algo avec un certain temps d'exécution..
Et pour finir, dans mon programme tt se passe en mémoire, avec ton idée il faut écrire sur le disque dur (côté serveur et client) et donc peut être encore un temps supplémentaire a ajouter et qui aura un impact sur les perf de rafraîchissement.
Tu peux essayer d'adapter ton idée et voir si les perf sont meilleur que celle de mon prog !

concernant UDP, ce protocole est beaucoup utilisé dans des applications qui transmettent des données type audio, video, .. (voix sur IP par exemple),
et pour la bonne raison qu'il est plus rapide que TCP car il n'y a pas de mécanisme de contrôle, et il me semble aussi que le trafique UDP et prioritaire
sur le réseau par rapport a TCP.
Dans mon programme la perte d'un paquet n'est pas dramatique et l'ordre d'arrivée des paquet n'a aucune importance, si tu regarde la structure qui est envoyé il y a un ensemble de pixels et les coordonnée pour chacun d'entre eux.
Messages postés
256
Date d'inscription
samedi 3 janvier 2004
Statut
Membre
Dernière intervention
30 mai 2016
4 >
Messages postés
23
Date d'inscription
samedi 19 avril 2008
Statut
Membre
Dernière intervention
1 février 2014

Quand j'aurais le temps je ferais des tests. En fait, pas besoin d'accéder au disque dur, suffit de faire le travail de compression en mémoire ; QT permet de travailler avec des fichiers en mémoire et non présent physiquement. Pour la compression ZIP, je crois que QT gère nativement le PNG, il s'agît ni plus ni moins qu'un BMP (Bitmap) mais compressé dans un ZIP, le fichier est potentiellement plus lourd que le JPEG mais l'agorithme de compression et décompression est beaucoup plus rapide, tout comme le traitement de l'image vu que tu as en résultat un simple bitmap (ce qui est le format le plus simple et rapide à lire malgré sa grande taille).

A voir si juste cela suffit à améliorer les performances ; on peut ensuite se tourner vers l'analyse, en effet une fois décompressé et le fait que tu n'as plus que des pixels (QPixmap gère ça très bien si j'ai bonne mémoire), suffit de mettre en relation l'ancienne image et la nouvelle pour en ressortir les pixels qui changent ; tu met alors juste à jour ton QPixmap.

Une autre possibilité c'est simplement la transmission des pixels, en gros côté serveur tu as détecté via une différence entre deux QPixmap, ce qui a changé, et tu transmets (d'où l'exemple du ZIP pour réduire la taille), les pixels qui changent. A l'arrivée, après décompression (si tu compresses), tu te retrouves juste à mettre à jour QPixmap.


Mais au niveau des performances, il faut savoir si c'est le serveur qui met trop de temps ou si c'est le client qui met trop de temps pour traiter les données reçues. Si c'est le client, avec une des mes idées je pense que tu peux sérieusement réduire le temps de traitement ; maintenant si c'est le serveur, c'est plus délicat et il faut faire un bon debug pour trouver la provenance exacte du soucis.

Sauf que l'ordre d'arrivé des données est importante, car imagine que tu reçois des informations correspondant à une fenêtre ouverte de l'autre côté (sur le serveur). Tu fermes la fenêtre puis en ouvre une autre ; manque de bol tu reçoit en premier l'ouverture de l'autre puis la fermeture de la première. Tu te retrouves donc à passer d'un coup de ta seconde fenêtre à un bureau vide car tu as reçu la fermeture de la première mais pas encore la seconde, qu'elle tu as eu juste avant.

L'UDP est utilisé pour la voix et c'est là le soucis, car souvent tu te retrouves justement avec des mots hachés ou incompréhensible justement.

En passant par de l'UDP, dans un remote desktop tu dois donc faire beaucoup de traitement afin que le paquet 2 reçu avant 1, que le résultat du calcul soit bien la contraction entre 1 et 2, donc soit retarder 2 pour traiter 1 puis 2, soit traiter 2 puis 1 mais attendre d'avoir bien eu les deux avant d'afficher.

Ton problème peut tout à fait venir de là d'ailleurs, ça reste à voir ;)
Messages postés
23
Date d'inscription
samedi 19 avril 2008
Statut
Membre
Dernière intervention
1 février 2014
>
Messages postés
256
Date d'inscription
samedi 3 janvier 2004
Statut
Membre
Dernière intervention
30 mai 2016

Oui c'est sans doute une bonne solution, il faudrait tester, malheureusement j'ai pas de temps actuellement pour modifier tt ca..
Concernant le transfert voila grosso modo le fonctionnement :
- Server : Il mitraille, il capture l'ensemble des pixels, les renverse et fait une comparaison avec la capture précédente (c'est ces 3 actions qui on une incidence sur le temps, j'ai pas fait de mesure mais je pense que c'est assez rapide), ensuite il envois les pixels qui on changé par bloque de X pixels.
- Client : Le client reçoit les bloques de données, quand il a reçut Y bloques une fonction qui s'exécute en parallèle traite ces données (mise a jour de l'affichage), mais le client continue de recevoir des données en provenance du serveur pour qu'il n'y ai pas d'interruption.

Donc je sais pas trop si c'est le client ou le serveur qui met trop de temps, je dirais le serveur par bon sens mais oui il faudrait faire des tests.
Messages postés
256
Date d'inscription
samedi 3 janvier 2004
Statut
Membre
Dernière intervention
30 mai 2016
4
Ton projet est intéressant et m'intéresse beaucoup (tan sur la partie programmation que pour le résultat, car je cherche un bon remote desktop depuis longtemps et que je pourrais utiliser depuis le boulot sans nécessité l'installation d'un driver comme UltraVNC ou TeamViewer).

Pour les pixels, au lieu de les envoyer, tu peux envoyer directement une capture d'écran compressée (ZIP, qui est géré nativement par QT, Deflate idem, bref tu as pas mal de choix ;) ) ; la transmission est plus rapide et pour le coup tu peux envoyer 20 voir 30 images par secondes, le client recevra sans exploser la connexion.

Le protocole UDP est intéressant, mais tu peux recevoir les paquets de données dans un ordre différent de l'envoi, voir même en perdre ; ce qui n'est pas idéal pour de l'accès à distance, le protocole TCP est à préféré dans ce type de projet.

Pour les captures d'écran, QT le gère nativement, et à voir mais je crois qu'il est capable aussi de détecter ce qui a changé entre deux captures (ou alors tu fais toi même l'algo de différenciation), de sorte que tu peux n'envoyer que les données de l'image qui ont changé, le tout compressé bien sur ; cela sera plus légers déjà que d'envoyer seulement des pixels même si ce n'est QUE ceux qui changent.
Afficher les 9 commentaires

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.