Résumé

  • CU-SeeMe abaissait le coût et les exigences matérielles du poste utilisateur, mais une conférence à plusieurs dépendait d’un réflecteur Unix séparé, le TCP/IP du Macintosh ne prenant pas en charge le multicast nécessaire au projet.
  • Le réflecteur rendait la conversation de groupe possible en copiant et en redistribuant les flux. Il concentrait aussi le débit, la configuration, les limites de participants, la visibilité et les règles d’usage sur un point partagé.

Une personne de plus, une architecture différente

La promesse initiale était volontairement concrète. Dans son article de mars 1995, Tim Dorcey décrit un logiciel de visioconférence pour Macintosh et Windows. Pour recevoir la vidéo, un ordinateur en réseau et un écran monochrome suffisaient. Pour émettre, il fallait une caméra et un numériseur ; Dorcey indique que l’ensemble caméra-numériseur pouvait se trouver à moins de 100 dollars pour Macintosh. Ce tarif ne correspond pas à un poste Internet complet. Les images en niveaux de gris et de faible définition répondaient aux limites des machines de l’époque.

Deux utilisateurs pouvaient se connecter directement. Une conférence plus large ne pouvait pas se contenter d’ajouter des liaisons identiques : chacun devait rejoindre un « réflecteur », un ordinateur Unix exécutant le logiciel CU-SeeMe et chargé de répliquer puis de redistribuer les paquets. Dorcey explique que le motif initial était l’absence de multicast dans l’environnement TCP/IP du Macintosh. Le poste produisait l’image ; la machine partagée construisait la salle.

Le multicast IP était pourtant déjà spécifié. Le RFC 1112 définissait depuis 1989 la prise en charge, par les hôtes, de l’émission et de la réception de datagrammes de groupe. La limite était plus précise : les outils TCP/IP pour Macintosh visés par CU-SeeMe n’offraient pas la fonction de réception multicast dont le projet avait besoin. Le réflecteur était une solution au manque d’une plateforme, pas la preuve que l’Internet entier ne savait pas faire du multicast.

Le point partagé coordonnait autant qu’il relayait

CU-SeeMe ne diffusait pas automatiquement tous les médias à tout le monde. Selon Dorcey, chaque client envoyait périodiquement un paquet OpenContinue décrivant les flux souhaités chez les autres participants : vidéo, audio ou diapositives. Le réflecteur analysait ces messages et construisait des listes de distribution propres à chaque source. Il servait donc à la fois à répliquer les paquets et à coordonner leur destination ; un média non demandé pouvait ne pas être transmis à un participant.

Cette souplesse avait une contrepartie : l’état courant de la conférence se trouvait dans le réflecteur, et chaque participant devait traiter des informations changeantes sur tous les autres. Dans son article de 1995, Dorcey estimait que le protocole passait mal à l’échelle au-delà d’environ 30 personnes, tout en fonctionnant de manière robuste pour des groupes plus petits. C’est une appréciation de l’évolutivité du protocole, pas une limite fixe appliquée à chaque configuration.

Le réflecteur devint aussi un lieu de rencontre. La page du projet Cornell le présentait comme indispensable aux conférences multipoints et avertissait que le logiciel répétait les flux de la conférence aux récepteurs. Une personne connectée à un réflecteur actif pouvait donc voir qui s’y présentait. Le point de rendez-vous était aussi une frontière de visibilité : le comportement de transfert déterminait qui pouvait observer qui.

La capacité se négociait par des règles d’usage

Les consignes conservées pour les utilisateurs montrent nettement les coûts partagés. La page de courtoisie de Cornell demandait de contacter l’opérateur, de ne pas rester des heures sans invitation, d’arrêter une émission d’image fixe laissée en marche, de plafonner le débit client à 100 kilobits par seconde et de vérifier l’effet sur une connexion partagée. Elle précisait qu’une image immobile pouvait consommer de la bande passante réseau et de la capacité du réflecteur. Ce n’étaient pas des conseils abstraits de protocole : quelqu’un d’autre possédait la ressource partagée.

Un guide destiné aux opérateurs, publié avec Internet TV with CU-SeeMe, proposait un exemple de dimensionnement : environ 80 kilobits par seconde pour une liaison jugée satisfaisante, 640 kilobits par seconde pour recevoir huit participants, puis 5,12 mégabits par seconde pour renvoyer les flux au groupe. Cette dernière valeur est une estimation illustrative du guide, pas un résultat mesuré. Elle montre néanmoins le mécanisme multiplicatif : le réflecteur devait recevoir le trafic, puis envoyer des copies. Le guide expliquait aussi pourquoi une machine Unix convenait à ce rôle — connectivité, puissance de calcul et fonctionnement prolongé — et exposait des limites réglables dans un fichier texte.

Un README de Cornell diffusé en mai 1993 invitait les utilisateurs à rester sous 100 kilobits par seconde sauf s’ils savaient où passait leur trafic ; un témoignage contemporain dit qu’un réflecteur avait accueilli jusqu’à six personnes. Aucun de ces nombres ne donne une capacité universelle. Ensemble, ils montrent que l’échelle dépendait de l’équipement local, du lien réseau, du paramétrage et du jugement de la personne maintenant le service disponible.

L’accès a déplacé le travail sans le supprimer

La rétrospective de Cornell situe la création du réflecteur après la demande, fin 1992, d’un responsable de programme de la NSF qui souhaitait un usage multipoint pour des élèves. Richard Cogger proposa le concept ; John Lynn développa le logiciel Unix séparé et Scott Brim apporta des critiques de conception au protocole. Une conférence du projet Global Schoolhouse relia des élèves de plusieurs États américains et de Londres. Cette chronologie explique pourquoi le réflecteur a été conçu : un vrai usage éducatif exigeait plus qu’une démonstration à deux personnes.

Dorcey décrit la contrepartie avec prudence. L’équipe cherchait à ne pas rendre les utilisateurs dépendants du réflecteur au-delà de la réplication et de la distribution, tout en reconnaissant qu’il permettait d’ajuster les flux aux destinataires. Il s’agissait d’un pont pratique, non d’une prétention à faire du serveur le maître de toute communication. Mais un pont suppose un hôte, un opérateur, une capacité suffisante et des règles pour ceux qui partagent la ressource.

En 1995, le projet avait étendu ses protocoles et ajouté notamment l’audio, la couleur, la messagerie textuelle et la gestion de bande passante. Ces évolutions élargissaient le service sans supprimer la question d’exploitation. Une caméra abordable pouvait rendre le poste accessible ; elle ne fournissait ni le débit montant de la salle, ni l’hôte Unix, ni la maintenance, ni l’arbitrage. CU-SeeMe abaissait une barrière et en déplaçait une autre.

Les sources ne démontrent ni un coût prohibitif des réflecteurs, ni une application uniforme des règles, ni un accès égal pour tous. Elles établissent toutefois le compromis architectural : le client rendait la participation assez peu coûteuse pour être essayée ; le réflecteur rendait le groupe possible en concentrant le travail dans un point partagé, limité en capacité et visible socialement.

Sources