Forum général.général XDMCP VS. VNC avec SSH

Posté par  .
Étiquettes : aucune
0
3
juil.
2006
Bonjour à tous et toutes,
voilà, je cherche à me connecter depuis chez moi (ADSL-512K/Kubuntu-Dapper/PC1) sur mon pc au bureau (ADSL-2Mo/Kubuntu-Breezy/PC2) qui se trouve derrière un firewall (IPCOP/FW). J'ai activé sur le firewall la redirection du port 22 vers celui de PC2, et depuis PC1 j'ai tenté deux approches, soit avec VNC, donc tightvncserver tournant sur PC2 (depth=8bits), j'ai fait depuis PC1:
vncviewer -via moi@FW localhost:1, ça marche pas trop mal, un tôt de rafraîchissement assez satisfaisant, par contre en me connectant avec:
ssh -C -g -X moi@FW puis dans la console de PC2 un
Xnest localhost:1, là ça rame à mort, j'ai le temps d'aller m'ouvrir une bière, de la siffler à moitié et de revenir pour avoir un premier rafraîchissement écran. Je pensais que vu que le déportage de l'affichage était natif pour X, ça irait plus vite que ça. Ai-je loupé une étape ou connaissez-vous un moyen plus efficace pour ne pas avoir à passer par VNC?
merci
  • # C'est simple

    Posté par  (site web personnel) . Évalué à 1.

    C'est relativement simple.
    En fait VNC compresse les données, essaye de mettre une vidéo dans le VNC
    tu va soufrire
    le protocole X envoie à chaque fois tout l'écran (sauf extention Damage qui est récente et qui ,de mémoire, nécessite composite), alors que pour VNC seulement les modifications sont envoyées.
    Sinon comme possibilités autres que VNC il y a NoMachine NX qui est un produit semi libre (la lib est libre pas la gui)
    Note:C'est pas XDMCP ici, c'est "juste" un X distant
    avec Xdmcp t'as pas besoin de ssh et tu te retrouve la plupart du temps sur un *dm (xdm, gdm, kdm pour les plus connus)
  • # Compromis

    Posté par  (site web personnel) . Évalué à 3.

    C'ets une histoire de compromis.

    Avec un réseau rapide et pas de latence (réseau local), le protocole X est le plus rapide et confortable.
    Via Internet, VNC donne souvent de bien meilleure résultat.

    Ce sont 2 protocoles differents. VNC va envoyer par le réseau les zones d'écran qui sont modifié sous forme d'image. X fait suivre les ordres de bases genre dessiner une ligne, un cercle, un point.

    Un avantage de X windows sur VNC meme via Internet, c'est que tu n'est pas obligé d'exporter tout le bureau, tu peux te contenter de lancer juste une appli, donc beaucoup moins de trafic. De plus, la lenteur de X via internet tient aussi beaucoup au trafic intrinsèque du toolkit utilisé. Qt est plus économe que Gtk. Les vielles versions de gtk sont très lentes, les dernières versions ont beaucoup progressé sur ce point.

    Autre point bloquant , c'est de faire passer X via ssh, ça introduit du lag car ssh met en tanpon le traffic X pour le compresser, le chiffrer et le renvoyer, Essaye sans la compression pour voir si cela améliore la réactivité...
    • [^] # Re: Compromis

      Posté par  . Évalué à 1.

      Justement, j'ai essayé sans la compression, c'est pire que tout. C'est bien du XDMCP que je veux faire puisque je veux accéder au DM avant de me logger, j'ai besoin de mon bureau entier et non d'une seule appli. Je ne comprend pas ton post Ph Husson je dois passer par internet et j'ai lu que XDMCP n'est pas sécurisé, donc bien obligé de crypter les échanges via ssh.
      • [^] # Où est le goulet ?

        Posté par  . Évalué à 2.

        Le goulet d'étranglement doit être la connexion internet. Ne confond pas le débit maximum de réception 512Kbits ou 2Mbits avec le débit d'émission qui est plus faible (probablement quelques dizaines de Kbits) et doit être insuffisant.
        Essaye de connecter tes deux machine par un réseau ethernet (deux cartes 100 et un cable croisé suffisent). Tu devrais voir immédiatement la différence. D'après mes tests, et suivant les logiciels graphiques lancés, un débit réseau de 100Kbits à 2Mbits est nécessaire. Ta connexion internet doit être incapable de fournir un tel débit.

        Pour utiliser XDMCP :
        * il faut lancer sur la machine serveur un gestionnaire de connexions (xdm, kdm, gdm ...) qui accepte les connections distantes,
        * puis lancer sur la machine cliente un serveur X avec l'option -query ou -broadcast.

        Comme tu utilises ssh, tu n'utilises pas XDMCP.

        Voici trois pistes pour gagner en vitesse :
        * diminue la résolution et le nombre de couleurs de ton serveur X.
        * utilise un bureau dépouillé (fluxbox par exemple à la place de kde ou gnome).
        * Pourquoi utiliser Xnest ? Tu peux lancer un deuxième serveur X sur PC1 et afficher ton bureau dessus :
        Dans un terminal, par exemple tty1, lance sur PC1 les deux commandes suivantes :
        X :1 &
        DISPLAY=:1 ssh -C -g -X moi@FW
        Puis lance dans la console sur PC1 ton bureau (startkde pour kde, fluxbox pour fluxbox ...). N'oublie pas d'indiquer le chemin absolu si besoin.
        PC1 va t'afficher deux bureaux qui affichent les fenêtres de programmes lancés sur PC1 pour le premier bureau et sur PC2 pour le second. Tu peux passer de l'un à l'autre avec les touches Ctrl+Alt+F7 ou bien Ctrl+Alt+F8.
        • [^] # Re: Où est le goulet ?

          Posté par  (site web personnel) . Évalué à 2.

          Très bonnes remarques mais je fais quand même 2 petites corrections:
          Effectivement lancer Xnest en ssh -X est sujet à surcharges inutiles du réseau
          Par contre le monsieur veut peut être éviter d'avoir 2 consoles virtuelles différentes, à ce moment il lance bien un Xnest mais en local, pas sur le ssh (ca consiste juste à remplacer X :1 par Xnest :1 en fait)
          Autre petite remarque, on peut crypter et compresser Xdmcp par ssh avec la fonction tunneling de ssh
          • [^] # Re: Où est le goulet ?

            Posté par  . Évalué à 1.

            Merci pour ces infos, je vais tester tout celà ce soir si le temps le permet (oh le gros n'orage méchant). J'avais lancé Xnest pour avoir la visu sur mon bureau, mais c'est vrai que rien ne m'empêche de lancer un deuxième X.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.