En quoi TeamViewer si vite ?

Question

Désolé pour la longueur, c'est un peu nécessaire.

Introduction

Je suis le développement d'un logiciel de bureau à distance (juste pour le fun) en C# 4.0 pour Windows Vista/7. J'ai obtenu à travers des obstacles de fond: j'ai une solide UDP système de messagerie, relativement propre conception du programme, j'ai un pilote de mise en miroir (la libre DFMirage pilote de mise en miroir de DemoForge) et en cours d'exécution, et j'ai mis en place le NAT traversal pour tous les types de NAT sauf Symétrique NATs (présent dans le pare-feu d'entreprise).

Concernant l'écran de transfert/partage, grâce au miroir pilote, je suis automatiquement informé de l'évolution de régions d'écran et je peux simplement maréchal le miroir pilote en constante mutation écran bitmap à ma propre image. Puis-je compresser la région d'écran au format PNG et de les envoyer sur le serveur de mon client. Les choses sont assez bonne, mais ce n'est pas assez rapide. C'est aussi lent que VNC (btw, je n'utilise pas le protocole VNC, juste une coutume amateur protocole).

À partir de la plus lente du logiciel de bureau à distance de la manière la plus rapide, la liste commence généralement à tous les VNC-like implémentations, puis grimpe sur Microsoft Windows Remote Desktop...et puis...TeamViewer. Pas tout à fait sûr de CrossLoop, LogMeIn - je ne l'ai pas utilisé, mais TeamViewer est incroyablement rapide. Il est tout à fait littéralement vivre. J'ai couru un tree commande sur Invite de commandes et mise à jour avec 20 ms de retard. Je peux naviguer sur le web en seulement quelques millisecondes plus lent que sur mon ordinateur portable. Défilement code verticalement dans Visual Studio a 50 ms temps de latence. Pensez à la façon robuste TeamViewer de l'écran de la solution de transfert doit être pour accomplir tout cela.

Inc utiliser sondage à base de crochets pour la détection de changement d'écran et de la force brute de capture d'écran/comparer à leur pire. À leur meilleur, ils utilisent un pilote de mise en miroir comme DFMirage. Je suis à ce niveau. Et ils utilisent ce qu'on appelle le protocole RFB.

Microsoft Windows Remote Desktop apparemment va pas plus haut que le VNC. J'ai entendu, à partir de quelque part sur StackOverflow, que le Bureau à Distance de Windows n'envoie pas d'écran bitmaps, mais, concrètement, les commandes de dessin. C'est tout à fait brillant, parce qu'il suffit de les envoyer de texte simple (tirage au sort ce rectangle à ces coordonnées et la couleur avec ce dégradé)! Remote Desktop est vraiment assez rapide et c'est la façon habituelle de travailler de la maison. Et il utilise ce qu'on appelle le protocole RDP.

Maintenant, TeamViewer est un mystère complet pour moi. Apparemment, ils ont sorti leur code source de la Version 2 (TeamViewer est la Version 7 février 2012). Les gens l'ont lu et a dit que la Version 2 est inutile - que c'est juste quelques améliorations au cours de VNC automatique NAT traversal.

Mais la Version 7...c'est ridiculement rapide maintenant. Je veux dire, c'est effectivement plus rapide que le Bureau à Distance de Windows. J'ai diffusé DirectX 3D jeux avec TeamViewer (à 1 fps, mais le Bureau à Distance de Windows n'autorise même pas de DirectX).

Par la voie, TeamViewer tout cela sans un pilote de mise en miroir. Il y a une option pour installer un, et il devient juste un peu plus rapide.

La Question

Ma question est, comment est TeamViewer si vite? Il ne doit pas être possible. Si vous avez de 1920 par 1080 de résolution à 24 bits de profondeur (16 bits de profondeur serait sensiblement moche), c'est encore 6,220,800 octets bruts. Même l'utilisation de la libjpeg-turbo (l'un des plus rapides de la compression JPG bibliothèques utilisées par les grandes entreprises), de la compression à 30 KO (soyons généreux), serait de prendre le temps de parcours à travers TeamViewer serveurs (TeamViewer contourne entreprise Symétrique NATs tout simplement par l'utilisation de proxy de trafic par le biais de leurs serveurs). Et que libjpeg-turbo-compression prendrais le temps de le compresser. De haute qualité de la compression JPG prend 175 millisecondes pour un plein de 1920 par 1080 capture d'écran pour moi. Et ce nombre est si l'hôte de l'ordinateur exécute un processeur Atom. Je n'ai tout simplement pas comprendre comment TeamViewer a optimisé leur écran de transfert si bien. De nouveau, la petite taille des images peut être très compressé, mais prenez au moins quelques dizaines de millisecondes pour compresser. De grande taille, les images prennent pas le temps de compresser, mais prendre un certain temps pour passer à travers. En quelque sorte, TeamViewer, complète cet ensemble du processus pour obtenir à peu près 20 à 25 images par seconde. J'ai utilisé un moniteur de réseau, et TeamViewer est encore lagless à des vitesses de 500 Kbit / s et 1 Mbit / s (VNC logiciel décalage de quelques secondes que le taux de transfert). Au cours de ma tree Invite de Commande de test, TeamViewer est de recevoir les données entrantes à un débit de 1 Mbit / s et toujours en cours de 5-6 fps. Et la VNC remote desktop ne pas le faire. Oui, comment?

Les réponses seront un peu compliqué et complexe, de sorte s'il vous plaît ne postez pas votre de 0,02 $si vous allez seulement à dire que c'est parce qu'ils utilisent UDP au lieu de TCP (croiriez-vous qu'ils font réellement l'utilisation de TCP juste avec autant de succès).

J'espère qu'il y a un TeamViewer développeur quelque part ici sur StackOverflow.

Les Réponses Possibles

Les mettra à jour une fois que les gens répondre.

1. Mes pensées sont, tout d'abord, que TeamViewer est très fin réseau de contrôle. Par exemple, ils se sont séparés de gros paquets à un peu moins de la taille de la MTU et ne perdez pas un voyage. Ils ont probablement toutes sortes de fantaisie crochets pour détecter les changements d'écran avec extrêmement rapide XOR comparaisons d'images.

Answer 1

La chose la plus fondamentale ici est probablement que vous ne souhaitez pas transmettre des images statiques, mais seulement des modifications aux images, qui, essentiellement, est analogue à flux vidéo.

Ma meilleure supposition est très efficace (et fortement spécialisé et optimisé) algorithme de compensation de mouvement, parce que la plupart des changements dans le générique de l'usage de bureau est linéaire en mouvement des éléments (texte défilant, le déplacement des fenêtres, etc. opposés à la transformation des éléments).

Le DirectX 3D performance de 1 FPS semble confirmer mon hypothèse, dans une certaine mesure.

Answer 2

prendrais le temps de parcours à travers TeamViewer serveurs (TeamViewer contourne entreprise Symétrique NATs tout simplement par l'utilisation de proxy de trafic par le biais de leurs serveurs)

Vous verrez que TeamViewer rarement besoin de relayer le trafic par le biais de leurs propres serveurs. TeamViewer pénètre NAT et réseaux compliquée par NAT à l'aide de NAT traversal (je pense que c'est de l'UDP de perforation, comme Google libjingle).

Ils utilisent leurs propres serveurs de milieu-homme pour faire de la poignée de main et connection set-up, mais la plupart du temps, la relation entre le client et le serveur sera P2P (dans le meilleur des cas, lorsque la main-shake est un succès). Si NAT traversal échoue, TeamViewer sera en effet le relais de trafic par le biais de ses propres serveurs.

Je ne l'ai jamais vu faire quand un client a été à l'origine de la double-NAT.

Answer 3

Un peu en retard à répondre, mais je vous suggère de jeter un oeil à un pas bien connu de projet sur codeplex appelé ConferenceXP

ConferenceXP est un open source, plate-forme de recherche simples, flexible et extensible de conférence et de collaboration à l'aide de haut-largeur de bande des réseaux et du multimédia avancé capacités de Microsoft Windows. ConferenceXP aide les chercheurs et les éducateurs de développer des applications innovantes et des solutions qui disposent d' qualité de diffusion audio et vidéo à l'appui en temps réel distribué la collaboration et les milieux d'apprentissage à distance.

La totalité du code source (c'est énorme!) est fourni. Il implémente le protocole RTP.

Answer 4

Il semble, en effet, comme le streaming vidéo plus que des images en continu, comme quelqu'un l'a suggéré. JPEG/PNG compression n'est pas ciblés pour ces types de vitesses, afin de les oublier.

Imaginez avoir un enregistrement de codec sur votre système qui peuvent en temps réel d'enregistrer l'arrivée d'un flux vidéo (votre écran). Un peu comme Fraps peut-être. Alors imaginez une lecture de la vidéo codec sur l'autre côté (le client distant). HD enregistreurs peuvent le faire (enregistrement live et même la lecture en direct à partir de la même HD), vous devriez faire de même, en fin de compte. La HD ne peut certainement pas de produire des images plus rapidement que vous pouvez lire votre écran, de sorte que n'est pas le goulot d'étranglement. Le goulot d'étranglement sont les codecs vidéo. Vous trouverez le codeur beaucoup plus d'un problème que le décodeur, comme tous les décodeurs sont pour la plupart gratuites.

Je ne dis pas que c'est simple; j'ai moi-même utilisé DirectShow pour encoder un fichier vidéo, et ce n'est pas en temps réel, et de loin. Mais étant donné le bon codec, je suis persuadé qu'il peut travailler.

Answer 5

Curieusement. mais dans mon expérience de TeamViewer n'est pas plus rapide/plus réactif que VNC, seulement plus facile à l'installation. J'ai un couple de win-boxen que je VNC sur OpenVPN (si il ya une autre surcharge de la couche) et c'est sur le Câble à bas prix (512) et je trouve correctement l'installation de TightVNC d'être beaucoup plus réactif que TeamViewer même boxen. RDP (naturellement) d'autant plus qu'en grande partie il envoie GUI dessiner des commandes à la place des tuiles de bitmap.

Ce qui nous amène à:

1. Pourquoi n'êtes-vous pas l'utilisation de VNC? Il y a pléthore de l'open source des solutions de, et Serré, c'est probablement sur le haut de la partie droite maintenant.

2. Avancé VNC implémentations à l'utilisation de la compression avec perte et qui semble atteindre de meilleurs résultats que votre choix de PNG. Aussi, SI le reste de la charge utile est également écrasé à l'aide de la librairie zlib. Bothj Serré et UltraVNC ont très optimisé algos, en particulier pour windows. Sur le dessus de que Serré, c'est open-source.

3. Si gagner boxen sont votre cible primaire RDP peut être une meilleure option, et a une opensource de mise en œuvre (rdesktop)

4. Si *nix boxen sont votre principal objectif NX peut être une meilleure option et a une implémentation open source (FreeNX, mais pas aussi optimisé que NoMachine produit exclusif).

Si la compression JPEG est un problème de performance pour votre algo, je suis assez sûr que la comparaison d'image encore loin des performances. Je serais prêt à parier qu'ils utilisent le meilleur des cas de compression pour chaque situation spécifique ie de perte de qualité pour les grandes images, certains rapide et sale internall losless pour les plus petits, comparer les bits des images et de les envoyer uniquement les différences de genre et des tas d'autres astuces d'optimisation.

Et beaucoup de ces trucs doivent être présents dans Serré > 2.0 car encore une fois, dans mon expérience, il bat l'enfer hors de TeamViewer performance wyse, YMMV.

Aussi le choix d'un JIT compilé exécution sur quelque chose comme C++ peut prendre une tranche de vos performances de pointe, en particulier dans la contrainte de mémoire des machines (beaucoup de réglage des performances de va aux toilettes démarrage de windows en utilisant le fichier d'échange de manière intensive). Et vous aurez besoin de la mémoire pour garder l'image précédente unis pour la comparaison interne au sommet de ce DF mirage vous donne.