Journal La transparence réseau et Wayland

Posté par  . Licence CC By‑SA.
Étiquettes :
44
21
fév.
2016

Cher journal,

Je sais que parfois tu t'inquiète que lors du passage à Wayland, tu vas perdre la transparence réseau. Et bien rassure-toi, Derek Foreman a pensé à toi, d'ailleurs, il y a pensé il y a deux semaines mais je n'ai pas vu passer l'info. Comme il l'écrit dans sa demande de patch, il a vu une présentation qui disait que si on poussais le protocole Wayland via TCP/IP, ce serait toujours une meilleure transparence réseau que X. Du coup, il l'a implémenté (facile, j'allais le faire aussi mais j'avais piscine). Alors, pour l'instant, ça n'est pas vraiment prêt, il n'y a d'ailleurs aucune sécurité. Ajouter son patch (d'une ligne1) dans Weston ouvre une socket qui permet à n'importe qui d'avoir accès au compositeur, mais ça a l'air d'être déjà utilisable (comme je le disais, j'ai piscine, du coup, je n'ai pas testé).

Il a décrit les trois problèmes majeurs de la transparence réseau dans Wayland.

  • Le premier est le passage de descripteurs de fichiers dans le protocole. Passer un descripteur de fichier via le réseau n'a pas beaucoup de sens. Un exemple d'utilisation de ces descripteurs est le passage de la keymap, le client reçoit un fd, fait un mmap dessus et peut le lire, les messages Wayland étant limités à 4kb et la keymap faisant plus que ça, ça permet de contourner le problème.
  • Le deuxième, qui me semble moins grave, ou plus facile à résoudre (pour ceux qui ne sont pas en maillot), c'est les input clavier, s'il y a un délais entre le message d'enfonçage de la touche et celui de ça libération, cela va générer une répétition de la touche non voulue.
  • Le troisième problème est le transfert de tampon entre le client et le compositeur qui se fait de plusieurs façon (mémoire partagée (mmap, dmabuf), extension mesa…). Ils ne sont pas prévu pour passer par le réseau.

Je ne vais pas décrire sa méthode de résolution du problème dans Wayland, parce que je ne connais pas assez le sujet. Il a en tout cas codé un système pour transférer tout ça via le réseau. Son implémentation a encore plusieurs problèmes qu'il relève :

  • Pas de compression des images via le réseau (encore une fois, ça ne me semble pas un problème insoluble)
  • Le « dammage tracking », c'est à dire la zone à redessiner en cas de changement est très mal calculé, il calcule juste un rectangle entre le deux points les plus éloignés qui ont changé. C'est-à-dire que si vous changez deux pixels à chaque coin de l'écran, il faut tout redessiner.
  • Le client doit utiliser wl_shm pour échanger son tampon, il n'est pas possible d'utiliser EGL ou dmabuf.

Pour plus d'information, je te laisse lire son article

  1. le reste du code n'est pas dans le compositeur, il n'a pas juste écrit une ligne de code. ↩

  • # ssh -X

    Posté par  . Évalué à -4. Dernière modification le 21 février 2016 à 23:14.

    Si c'est aussi simple que de faire un ssh -X, alors c'est ok pour moi. Comme cela passe par du tcp, je pense qu'une redirection de port via ssh et une variable d'environement suffiront.

    Si ce n'est pas l'un de leurs buts, ils peuvent revoir leur copie.

    • [^] # Re: ssh -X

      Posté par  . Évalué à 5.

      Sachant qu'aujourd'hui la transparence réseau est déjà pas mal pétée par les extensions modernes,
      sachant qu'ils semble plutôt être il, et je ne pense pense pas qu'il te doive quelque chose,
      j'aimerais bien savoir au nom de quelle autorité légitime tu te permettrais de le renvoyer voir leur/sa copie?

      • [^] # Re: ssh -X

        Posté par  . Évalué à -8.

        Tu as raison. soyons authoritaire : Je vais lui envoyer un mail. Mais je vais écrire cette fois : "Il faut qu'ils revoient leur copie". Ce n'est pas ici qu'ils vont me lire.

        Non, mais c'est un commentaire qui donne un avis sur un sujet qui fait normalement au moins 50 commentaires en 2 heures (mais là rien) avec un "peuvent".

        Va FALLOIR que je revoie mon vote au sondage http://linuxfr.org/sondages/que-pensez-vous-de-la-convivialite-des-personnes-frequentant-linuxfr-org .

      • [^] # Re: ssh -X

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

        Et puis si c'est pour avoir de la transparence réseau uniquement pour les applis utilisant OpenGL < 2 comme maintenant avec Xorg. On va vite être limité dans le futur.

    • [^] # Re: ssh -X

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

      Notez que ssh -X n'utilise pas nécessairement la transparence réseau de X11, en ce sens que, pour le client et le serveur X, le protocole X n'est pas forcément envoyé et reçu par réseau, mais peut l'être par socket Unix.

      Pour être plus clair, voici ce que fait ssh -X ou ssh -Y :

      1. sur le serveur SSH distant sur lequel on se connecte, ouvrir, selon la version ou la configuration je pense, une connexion TCP en écoute sur 127.0.0.1:6010 ou [::1]:6010, ou le socket socket Unix /tmp/.X11-unix/X10 ;
      2. transférer tout ce qui y est reçu sur le socket Unix /tmp/.X11-unix/X0 sur la machine locale ;
      3. exporter DISPLAY=localhost:10 dans le shell distant.

      (si le DISPLAY=:10 est déjà pris sur le serveur SSH distant, ça utilise DISPLAY=:11, en écoutant sur TCP [::1]:6011 ou /tmp/.X11-unix/X11, et ainsi de suite si :11 est déjà pris)

      Le véritable transfert par réseau est donc fait par SSH et n'utilise pas la capacité de faire du X11 par réseau.

  • # mouais...

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

    Je crois que la gestion de la sécurité en rapport avec les input device avait pris récemment un temps conséquent. Je pense qu'il sous-estime très largement le problème. Je n'ai jamais vu un protocole réseau correct, quand la sécurité est pensé "ensuite" (latence d'une communication TLS classique, problème de gestion des attaques MiM dû problème de vérification des clefs public, etc…).

    Concernant les images, le plus simple est de les transmettre tel-quel, n'importe quoi est capable de lire un gif, un jpeg ou un png ou une texture compressé.

    "La première sécurité est la liberté"

    • [^] # Re: mouais...

      Posté par  . Évalué à 5.

      Je suis assez d'accord concernant la difficulté de sécuriser correctement un protocole à prostériori.
      Par contre, l'utilisation de SSH (ou tout autre système s'apparentant à un VPN) pour encapsuler le flux est une assez bonne approche.

      Pour ce qui est des images, le problème n'est pas de les transférer mais de le faire efficacement. Les volumes de données brutes sont énormes. Une seule fenêtre en HD 1920x1024-24bit représenterait un flux brut de 56MB/s (450Mbit/s) pour obtenir 10 frame/s. Ce n'est pas réaliste sans techniques de compression avancées et si possible en n'utilisant qu'une fraction négligeable du temps CPU. Wayland se dirige vers une approche de type 'remote desktop' à la VNC ; cela fonctionnera mais uniquement pour un nombre très réduit d'utilisateurs simultanés par serveur.

      • [^] # Re: mouais...

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

        Ils peuvent toujours faire de la compression mpeg4 avec quelques frames pour éviter d'avoir trop de latence. Le mpeg4 est gourmand mais toutes les puces (sauf intel ?) viennent avec leur compresseurs mpeg4 hardware.

        "La première sécurité est la liberté"

        • [^] # Re: mouais...

          Posté par  . Évalué à 2.

          Le mpeg4 est gourmand mais toutes les puces (sauf intel ?)

          Intel Quicksync est dispo depuis SandyBridge.

  • # clic milieu

    Posté par  . Évalué à 7.

    moi la question qui me tarabusque, c'est est-ce qu'avec Wayland la possibilité de coller avec le clic du milieu un texte précédemment sélectionné va continuer à fonctionner. Déjà que dans gnome et/ou certains outils gtk cette fonctionnalité a été bien mise à mal…

    « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher

Suivre le flux des commentaires

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