!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> Rendezvous
  1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

Mac OS X 10.2 : Jaguar (7)




Rendezvous

Rendezvous est le nom de marque d'Apple pour une technologie difficile à expliquer à un utilisateur moyen, et potentiellement encore plus difficile à commercialiser. Je vais aborder le sujet sous des angles différents. Voici d'abord l'aspect technique et bienveillant de la chose.

La technologie.

Rendezvous supporte quatre services importants :
1. Autoconfiguration de l'interface IP.
2. Correspondance entre les noms d'hôte et les adresses IP
3. Découverte des services
4. Allocation d'adresse IP de diffusion

Les deux premiers éléments correspondent à des services dont vous disposez sans doute déjà. Vos interfaces de réseau doivent se configurer automatiquement en recourant à un serveur DHCP. La correspondance entre les noms d'hôte et les adresses IP se fait avec l'aide d'un ou de plusieurs serveurs DNS (elle peut aussi être configurée par votre serveur DHCP). La découverte des services rappelle quelque chose qui est déjà géré par un des nombreux répertoires de services existants (par exemple Active Directory sous Windows). Le dernier élément de la liste semble quelque peu ésotérique. Alors, qui a vraiment besoin de ces services ?

Les choses semblent un peu plus claires quand la liste des services est réécrite en terme de technologies existantes dans les mêmes domaines. Comment percevez-vous cette liste légèrement modifiée ?
1. Allocation d'adresse sans serveur DHCP.
2. Correspondance entre noms et adresse IP sans serveur DNS.
3. Recherche de services, comme des imprimantes, sans un serveur de répertoire
4. Allocation d'adresse de diffusion sans un serveur MADCAP.

Tout d'un coup, nous sommes passés d'une liste de services apparemment sans intérêt à un ensemble de possibilités qui deviennent magiques. Le dernier élément semble encore sans intérêt, mais c'est en fait une indication importante sur la façon dont tout le système fonctionne.

Dit simplement, Rendezvous permet à un réseau local de périphériques de se configurer tout seul, sans l'aide de serveurs spécialisés. Le mot principal est "local", parce que Rendezvous ne s'applique que dans le cadre d'un réseau limité. Rendezvous n'est pas conçu pour s'adapter à tout le réseau Internet. Il s'applique à des réseaux de taille petite ou moyenne.

La magie opère grâce à la coopération. Les périphériques participants se parlent entre eux pour déterminer qui a telle adresse et tel nom d'hôte. Cette communication se fait en diffusant des adresses IP.

Pour démarrer, tous les périphériques participants communiquent à l'origine en utilisant une adresse de diffusion bien connue (autrement dit pré-définie). La première étape, pour chaque périphérique, est d'assigner une adresse IP unique à toutes ses interfaces sur le réseau. Ces adresses "auto-assignées" sont puisées dans un bloc d'adresses spécial réservé à cela : 169.254/16.

( Cette gamme d'adresses peut sembler familière à ceux d'entre-vous qui ont vu une machine incapable de récupérer une adresse à partir du serveur DHCP, et qui finit par s'assigner directement (auto-assignation) une adresse dans cette gamme).

Avant de continuer, il est important de souligner que ces adresses auto-assignées peuvent être (et le seront probablement) définies en plus d'une adresse IP "normale" pour le périphérique. Rappelez vous qu'une seule interface de réseau peut supporter des adresses IP multiples.

Evidemment, l'astuce des adresses IP auto-assignées est de s'assurer que deux hôtes ne s'attribuent pas la même adresse. Pour résoudre ces conflits, les hôtes qui supportent Rendezvous sont capables de poser des questions simples (en utilisant des adresses IP de diffusion bien connues), comme "est-ce que quelqu'un a déjà cette adresse ?" La résolution des conflits d'adresse est en réalité faite dynamiquement en continu, plutôt qu'une seule fois au moment où le périphérique est configuré. C'est rendu possible parce que tous les services Rendezvous partagent la même organisation de configuration dynamique.

Prenons le service numéro deux, par exemple : la correspondance entre les noms d'hôtes et les services IP. Comme les adresses IP peuvent changer à n'importe quel moment au cours de la résolution dynamique des conflits d'adresse, les noms d'hôtes et leur récupération doivent aussi être assignés dynamiquement, en continu. A nouveau, des adresses IP de diffusion bien connues sont utilisées pour poser des questions comme "est-ce que quelqu'un d'autre utilise ce nom d'hôte ?" et "quelle adresse IP correspond actuellement au nom d'hôte machin ?"

Rappelez-vous qu'il n'y a pas de serveur central, si bien que les réponses à ce type de questions ne viennent que d'une source digne de confiance : les autres hôtes eux-mêmes. Chaque hôte doit répondre aux questions qui le concernent, les seules questions auxquelles il peut répondre avec certitude.

Remarquez que ces noms d'hôte Rendezvous n'ont de signification qu'au sein du réseau courant, et existent en plus des noms d'hôte du réseau internet "normal" qui peuvent être associés avec le périphérique.

Etant donné ce réseau de périphériques spécifique, le troisième élément, "recherche des services" est tout simple. Les périphériques demandent au réseau dans son ensemble "est-ce que quelqu'un fournit le service Truc ?" Tout périphérique du réseau qui fournit ce service Truc va répondre en disant "je fournis ce service".

On en arrive maintenant au dernier élément de la liste : l'allocation d'adresse IP de diffusion. Ce service est utilisé pour allouer dynamiquement des adresses IP de diffusion propres à une application. Plutôt que d'utiliser des adresses de diffusion "bien connues" (que chaque périphérique surveille) pour toutes les communications, les périphériques peuvent réclamer l'utilisation d'une adresse de diffusion privée pour un aspect donné du réseau. Comme vous pouvez vous y attendre, tous les périphériques participants coopèrent pour partager un ensemble fini d'adresses de diffusion proposé par le bloc d'adresses réservé à cet effet.

A vrai dire, ces services ont tous été fournis par des technologies précédentes, comme AppleTalk, NetBios, et IPX. La première chose qui rend Rendezvous différent est que c'est un standard ouvert. Rendezvous est simplement le nom pris par Apple pour son implémentation des technologies proposées par le groupe de travail Zero Configuration Networking (Zéroconf) de l' IETF (Internet Engineering Task Force). Apple ne "possède" pas cette technologie, pas plus qu'elle ne possède son propre réseau IP ou tout autre standard Internet.

La seconde chose qui rend Rendezvous différent, est qu'il est construit en utilisant la technologie de réseau IP existante. Il communique en utilisant le réseau IP standard. Il utilise des paquets de requête DNS standard pour la résolution des noms. Les périphériques et les adresses de diffusion sont alloués à partir de blocs d'adresses spécialement réservés à cet effet. Il n'y a rien de propre ou de spécifique à Apple là dedans, et c'est conçu pour fonctionner sur les réseaux IP existants sans avoir besoin de les modifier et sans provoquer d'interférence en quoi que ce soit.

Les administrateurs de réseau qui liront ceci peuvent être réservés parce qu'ils envisagent les controverses de diffusion du réseau et d'autres comportements étranges qui ont été définis par des protocoles propriétaires précédents. La spécification Zéroconf a été écrite dans cet esprit, malgré tout, et elle comporte des restrictions sur de tels comportements. Il reste à appréhender exactement à quel point les premières implémentations de Zéroconf sont moins bavardes, mais l'utilisation des formats de paquets existants et les techniques d'adressage vont à coup sûr procurer une longueur d'avance sur les protocoles propriétaires qui ont chacun leurs propres paquets propriétaires encapsulés dans des paquets standard IP avant la transmission.


Historique.

Un coup d'œil à l'histoire de Rendezvous est instructif aussi. Comme je l'ai dit précédemment, Rendezvous est le nom de marque d'Apple pour son implémentation du standard Zéroconf. Zéroconf, à son tour, prend ses racines dans une discussion sur la liste de diffusion des programmeurs réseau du Mac en 1997. L'idée était de fournir aux réseaux IP les mêmes facilités que celles dont on bénéficiait avec les réseaux Appletalk.

Depuis 1997, Apple est passée d'AppleTalk au réseau IP, et dans l'aventure, elle a perdu certaines de ses facilités historiques d'utilisation. Il n'est donc pas surprenant qu'un standard conçu pour rendre le réseau IP plus familier ait été initié, et finalement ait abouti chez Apple.

A chaque incursion dans le monde des standards, Apple améliore son comportement et son taux de succès. L'Apple des anciens mauvais jours souffrait d'un cas sévère du syndrome "pas inventé ici", et prétendait inventer ses propres standards propriétaires pour à peu près n'importe quoi. Cela a souvent permis à Apple de surpasser les technologies existantes, en particulier dans le domaine le plus important pour Apple : la facilité d'utilisation. AppleTalk en est un exemple remarquable. Il a fournit une expérience très familière du réseau pour tout le monde bien avant que la facilité d'utilisation soit devenue un centre d'intérêt pour la plupart des autres standards de réseau.

L'inconvénient des standards propriétaires, c'est qu'il est très difficile de les faire adopter par le reste de l'industrie. Personne de veut enchaîner une partie de ses affaires à une technologie tenue et contrôlée par un concurrent. Un standard qui n'est pas adopté par le reste de l'industrie en souffre de plusieurs façons. D'abord, le coût entier du développement doit continuer à être supporté par une seule compagnie, plutôt que d'être partagé par l'industrie toute entière. Ensuite, un marché réduit signifie des volumes plus faibles, des prix plus élevés, et des choix moindres. Pour finir, inévitablement, les standards ouverts à échelle industrielle rattrapent en définitive la technologie propriétaire, et en font un ilot d'inter-opérabilité.

AppleTalk a souffert de tous ces maux. Le choix d'Apple d'abandonner AppleTalk et de se tourner vers le réseau IP était inévitable, largement dû à l'explosion d'Internet. Mais ce changement a rencontré une certaine résistance, parce que le réseau IP n'avait pas encore atteint le niveau d'AppleTalk en termes de facilité d'utilisation. Rendezvous comble finalement le fossé, en fournissant les quelques services propres à AppleTalk dont le réseau IP manquait.

Ce qui est le plus important, c'est qu'Apple a réalisé cela non pas en définissant une nouvelle extension au réseau IP propriétaire et qui lui soit propre, mais en travaillant " au sein du système" pour aider à définir un standard ouvert compatible avec les réseaux existants.

Il est à coup sûr beaucoup plus facile (et plus rapide) de créer unilatéralement un nouveau standard propriétaire. Cette interview de Stuart Cheschire, dirigeant du groupe de travail Zéronconf et employé d'Apple donne un aperçu des difficultés à convaincre l'IETF que la "facilité d'utilisation" était une qualité importante que doit avoir un réseau IP. Voici ce qu'il dit sur le sujet :

L'IETF est en général constitué de gens qui accordent très peu d'attention à la facilité d'utilisation [...] Même maintenant, cela reste le centre d'intérêt d'une minorité à l'IETF. La plupart des gens de l'IETF travaillent pour des vendeurs de routeurs, des FAIs, des fournisseurs de dorsales internet, des compagnies de téléphone, et leur objectif est le réseau à grande échelle. Si vous travaillez pour une société qui fabrique des routeurs, vous n'allez pas être très motivé(e) par une technologie qui permet aux ordinateurs de communiquer directement entre eux, sans routeur. Si vous travaillez pour une compagnie qui vend des serveurs DHCP, vous n'allez pas être très excité par une technologie qui permet aux ordinateurs de communiquer sans avoir besoin d'un serveur DHCP. Si vous travaillez pour une compagnie qui vend des serveurs DNS, vous ne serez pas très excité par une technologie qui permet aux ordinateurs de communiquer sans recourir à un serveur DNS. Je suis sûr que vous avez compris.

Mais la facilité d'utilisation est fondamentale pour l'utilisateur final, et devient encore plus importante à mesure que de plus en plus de produits associables au réseau sont introduits. Alors, pour finir, considérons Rendezvous dans la perspective de l'utilisateur.


Les applications pour l'utilisateur.

Beaucoup de fanas d'ordinateurs sont fiers de leur réseau personnel soigneusement constitué, capable de supporter beaucoup de PCs, d'imprimantes, et d'autre périphériques. Mais même les meilleurs réseaux personnels ont des difficulté à s'étendre, et il est très courant même pour des gens qui se disent geeks, de batailler pour réussir à ce que chaque périphérique puisse communiquer sûrement avec n'importe quel autre. Quand un ami arrive avec son portable, le réseau personnel est mis à l'épreuve quand le nouvel élément cherche à s'y joindre.

Et c'est le meilleur des cas possibles. La plupart des utilisateurs d'ordinateurs personnels n'ont aucune idée de la façon de créer un réseau comme celui décrit ci-dessus, ce qui évidemment est un sujet de fierté des geeks pour leur réseau.

Maintenant, imaginez un monde où la création d'un réseau personnel est aussi simple que de connecter tous les périphériques avec des câbles ethernet (d'accord, vous pouvez saboter cela aussi, mais restez avec moi) et de les mettre sous tension. Sans aucun effort supplémentaire, chaque périphérique peut voir tous les autres, et peut poser des questions intéressantes comme "est-ce qu'il y a une imprimante disponible ?" ou "y a-t-il un serveur de MP3s ?"

Comme je l'ai dit précédemment, les fonctions de Rendezvous se font sur une échelle limitée. Ce serait bien si la totalité de l'internet pouvait s'auto-configurer, mais c'est un problème autrement plus compliqué à aborder. Si bien que tout réseau personnel aura toujours affaire aux bizarreries de NAT et de DHCP, et au reste de la soupe qui permet à chaque ordinateur de la maison de se brancher sur le site web de arstechnica.com.

Mais pour certaines catégories de périphériques, la communication locale est beaucoup plus importante qu'un simple nœud sur Internet. Ce que fait Rendezvous, c'est de fournir un domaine de communication séparé, entièrement auto-configurable, dédié aux échanges locaux de données.

Arrêtez de penser en termes de PCs et de sites web un instant, et pensez à vos enregistreurs vidéo personnels, à vos systèmes stéréo, à vos lecteurs de DVDs. La possibilité d'écouter votre collection de MP3 sur n'importe quel élément stéréo dans la maison ou (pour utiliser l'exemple de Start Cheschire) de voir des programmes stockés sur un ou plusieurs Enregistreurs Vidéo Personnels sur n'importe quelle TV de la maison est très attirante. Mais vous ne voudrez sans doute pas partager vos habitudes de regarder la télé avec le monde entier, si bien que le domaine local restreint du réseau de Rendezvous devient un avantage, et même un facteur de sécurité.

Cela n'est pas bien difficile d'imaginer comment Apple peut tirer parti de cette technologie. Comme nous allons le voir un peu plus tard, Jaguar comprend quelques applications intéressantes de Rendezvous, et d'autres qui vont sûrement suivre dans les mois à venir.