Resumen

  • CU-SeeMe redujo el precio y los requisitos del equipo de usuario, pero sus reuniones con varias personas dependían de un reflector Unix separado porque el TCP/IP de Macintosh no ofrecía el multicast que el proyecto necesitaba.
  • El reflector permitía la conversación de grupo al copiar y redistribuir flujos; también concentraba ancho de banda, configuración, límites de participantes, visibilidad y reglas de uso en un punto compartido.

Una persona más cambiaba la arquitectura

La promesa original era concreta. En su artículo de marzo de 1995, Tim Dorcey describió CU-SeeMe como un programa de videoconferencia para Macintosh y Windows. Para recibir vídeo bastaban una conexión de red y un monitor en escala de grises. Para transmitir hacían falta una cámara y un digitalizador; Dorcey afirmó que el conjunto para Macintosh podía adquirirse por menos de 100 dólares. Ese precio no cubría una instalación completa de Internet, y las imágenes pequeñas en tonos grises respondían a la capacidad de los ordenadores disponibles.

Dos participantes podían conectarse directamente. Una conferencia mayor necesitaba otra arquitectura: cada participante se conectaba a un «reflector», un ordenador Unix con software CU-SeeMe que replicaba y redistribuía los paquetes. Dorcey explicó que el motivo inicial fue la falta de multicast en las instalaciones TCP/IP de Macintosh. El ordenador personal generaba la imagen; una máquina compartida montaba la sala.

El multicast IP ya estaba especificado. RFC 1112 había definido en 1989 cómo los equipos enviaban y recibían datagramas dirigidos a grupos. La limitación era más estrecha: el entorno TCP/IP para Macintosh al que se dirigía CU-SeeMe no ofrecía la recepción multicast necesaria para el proyecto. El reflector resolvía una carencia de plataforma; no demostraba que Internet en su conjunto careciera de multicast.

El punto compartido también coordinaba

CU-SeeMe no enviaba necesariamente todo a todos. Según Dorcey, cada cliente transmitía periódicamente un paquete OpenContinue que expresaba qué medios deseaba de los demás: vídeo, audio o diapositivas. El reflector examinaba esos mensajes y construía listas de distribución para cada fuente. Además de replicar paquetes, coordinaba sus destinatarios; podía evitar que llegara un medio que alguien no había solicitado.

La flexibilidad situaba el estado vivo de la conferencia en el reflector y exigía que cada participante procesara información cambiante sobre todos los demás. Dorcey consideró que el protocolo escalaba mal por encima de unas 30 personas, aunque funcionaba con solidez en grupos pequeños. Esa cifra expresa su evaluación de escalabilidad en el artículo de 1995; no era un máximo fijo para toda configuración de reflector.

El reflector también se convirtió en un lugar donde encontrarse. La página del proyecto Cornell decía que era imprescindible para las reuniones multipunto y avisaba de que el software repetía los flujos a los receptores. Cualquier persona conectada a un reflector activo podía ver quién entraba. El punto de encuentro trazaba también un límite de visibilidad: el comportamiento de reenvío determinaba quién podía observar a quién.

La capacidad se convertía en cortesía

Las instrucciones conservadas para usuarios hacen visibles los costes compartidos. La página de Cornell pedía contactar al operador, no permanecer horas sin invitación, no dejar imágenes fijas transmitiéndose, limitar el cliente a menos de 100 kilobits por segundo y comprobar el efecto sobre conexiones compartidas. Advertía que una imagen inmóvil consumía tanto ancho de banda de red como capacidad del reflector. No era una recomendación protocolaria abstracta: otra persona era responsable del recurso común.

Una guía para operadores publicada con Internet TV with CU-SeeMe ofrecía un cálculo orientativo: unos 80 kilobits por segundo para una conexión razonable, 640 kilobits por segundo para que el reflector recibiera ocho participantes y 5,12 megabits por segundo para reflejar los flujos al grupo. La última cifra es una estimación ilustrativa de la guía, no una medición. Aun así, muestra la multiplicación del trabajo: primero recibir, después enviar copias. La guía recomendaba Unix por su conectividad, capacidad de cómputo y funcionamiento prolongado; también describía controles editables en archivos de texto para limitar participantes y emisores.

Un README de Cornell distribuido en mayo de 1993 aconsejaba mantener los topes por debajo de 100 kilobits por segundo salvo que el usuario supiera dónde terminaba el tráfico. Un testimonio de la época decía que un reflector había atendido hasta seis participantes. Ninguno de esos datos establece un límite universal. En conjunto apuntan a una escala que dependía del equipo, el enlace, la configuración y el criterio del operador.

La accesibilidad desplazó el trabajo, pero no lo eliminó

La historia institucional de Cornell sitúa el reflector después de que, a finales de 1992, un responsable de programa de NSF preguntara si CU-SeeMe podía servir para una actividad multipunto con escolares. Richard Cogger propuso el concepto; John Lynn desarrolló el programa Unix y Scott Brim aportó críticas de diseño al protocolo. Una conferencia del proyecto Global Schoolhouse conectó a estudiantes de varios estados de EE. UU. y Londres. La secuencia explica el origen del reflector: el uso educativo real exigía algo más que una demostración entre dos personas.

Dorcey describió el intercambio con cautela. El equipo intentó que los usuarios no dependieran del reflector más allá de la replicación y la distribución, aunque reconoció que el servidor podía adaptar los flujos a cada receptor. Era un puente práctico, no una pretensión de que un servidor dirigiera toda comunicación. Pero todo puente necesita un anfitrión, una persona operadora, capacidad suficiente y reglas para quienes lo comparten.

En 1995 el proyecto había ampliado los protocolos y añadido, entre otras cosas, audio, color, chat y gestión del ancho de banda. Esas mejoras extendían el servicio sin borrar la pregunta operativa. Una cámara asequible podía abaratar el extremo del usuario; no proporcionaba el ancho de banda ascendente de la sala, el host Unix, el mantenimiento ni la coordinación. CU-SeeMe redujo una barrera y trasladó otra.

Las fuentes no demuestran que alojar reflectores fuera prohibitivo, que todos los operadores aplicaran las reglas ni que el acceso fuera igualitario. Sí documentan el intercambio arquitectónico: el cliente hacía asequible probar la participación; el reflector hacía posible el grupo al concentrar trabajo en un punto compartido, limitado por capacidad y visible para sus usuarios.

Fuentes