Remote Desktop
ganjarasta
Messages postés
23
Date d'inscription
samedi 19 avril 2008
Statut
Membre
Dernière intervention
1 février 2014
-
1 août 2013 à 09:59
akablood - 28 juil. 2016 à 04:14
akablood - 28 juil. 2016 à 04:14
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/100042-remote-desktop
https://codes-sources.commentcamarche.net/source/100042-remote-desktop
Modifié par BunoCS le 28/07/2016 à 10:49
quelqu'un peut m'aider
19 janv. 2014 à 00:34
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.
20 janv. 2014 à 17:16
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 ;)
1 févr. 2014 à 13:00
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.
16 janv. 2014 à 15:09
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.
20 août 2013 à 15:13
En tout ca ça me semble propre =)
23 août 2013 à 15:33
8 sept. 2013 à 13:23
1 août 2013 à 09:59