요약

  • CU-SeeMe는 엣지에서의 가격과 컴퓨터 요구 사양을 낮췄지만, 당대 매킨토시 TCP/IP 소프트웨어가 멀티캐스트를 지원하지 않았기 때문에 다자간 모드는 별도의 Unix 리플렉터에 의존했다.
  • 리플렉터는 스트림을 복제하고 선택적으로 재분배해 그룹 통화를 실용적으로 만들었지만, 동시에 대역폭, 설정, 참여자 한도, 가시성, 운영 예절을 하나의 공유 지점에 집중시켰다.

추가된 한 사람이 아키텍처를 바꿨다

최초의 약속은 소박하고 구체적이었다. Tim Dorcey의 1995년 3월 글은 매킨토시와 Windows용 데스크톱 화상회의 프로그램을 다루었다. 영상 수신에는 네트워크 연결과 그레이스케일 모니터가, 송신에는 카메라와 디지타이저가 필요했다. Dorcey는 매킨토시용 카메라·디지타이저 통합 장치를 100달러 미만에 구입할 수 있다고 말했다. 이는 완전히 동작하는 인터넷 구성 전체의 비용이 아니라 부품 가격이었고, 응용 프로그램의 저해상도 그레이스케일 영상은 당시 컴퓨터를 고려한 의도적인 절충이었다.

참가자 두 명은 직접 연결할 수 있었다. 더 큰 회의를 이 방식으로 단순히 반복할 수는 없었다. Dorcey에 따르면 각 참가자는 “리플렉터”에 접속했는데, 이는 CU-SeeMe 소프트웨어를 실행하며 패킷 스트림을 복제·재분배하는 Unix 컴퓨터였다. 그가 기술한 리플렉터의 원래 목적은 매킨토시에 멀티캐스트 기능이 없다는 점이었다. 단말이 화면을 만들 수 있었다면, 공용 컴퓨터가 회의 공간을 만들었다.

이 구분이 중요한 이유는 IP 멀티캐스트가 이미 규격화되어 있었기 때문이다. RFC 1112는 1989년에 그룹 데이터그램의 송수신을 위한 호스트 지원을 정의했다. 한계는 더 좁았다. CU-SeeMe가 대상으로 한 매킨토시 TCP/IP 기능에는 이 프로젝트에 필요한 멀티캐스트 능력이 없었다. 리플렉터는 플랫폼의 공백에 대한 응용 계층의 답이었지, 인터넷 전체가 멀티캐스트를 갖지 않았다는 증거가 아니었다.

공유 지점은 단순히 패킷을 전달하는 것 이상을 했다

CU-SeeMe는 모든 참가자를 동일한 송수신 파이프처럼 취급하지 않았다. Dorcey의 설명에 따르면 각 클라이언트는 주기적으로 OpenContinue 패킷을 보내 다른 참가자의 영상, 오디오 또는 슬라이드에 대한 자신의 관심을 알렸다. 리플렉터는 이 메시지를 검토해 발신자별 배포 목록을 만들었다. 따라서 리플렉터의 역할은 복제와 조율 둘 다였다. 수신자가 원하지 않는 미디어는 보내지 않을 수 있었다.

이는 유용한 유연성이었지만, 실시간 회의 상태를 리플렉터에 두게 만들었고 각 참가자가 다른 모든 참가자에 대한 변화하는 정보를 처리하도록 했다. Dorcey는 이 프로토콜이 대략 30명을 넘는 대형 회의에는 부적합하다고 판단하면서도, 소규모 그룹에서는 견고하게 동작한다고 말했다. 이 수치는 1995년 논문에서 기술한 프로토콜의 확장 행동이며, 모든 리플렉터 설정에 적용된 고정 상한은 아니다.

리플렉터는 또한 사람들이 서로를 찾을 수 있는 장소가 되었다. Cornell의 프로젝트 페이지는 리플렉터를 다자간 사용에 필수적이라고 설명하면서, 소프트웨어가 회의 스트림을 수신자에게 반복 전송한다고 경고했다. 활성화된 리플렉터에서 접속한 누구나 누가 접속했는지 볼 수 있었다. 만남의 장소는 곧 가시성 경계이기도 했고, 소프트웨어의 전달 동작은 누가 누구를 관찰할 수 있는지를 결정했다.

용량은 예절의 문제가 되었다

남아 있는 운영자 지침은 비용을 이례적으로 분명하게 보여준다. Cornell의 리플렉터 예절 페이지는 방문자에게 운영자에게 연락할 것, 초대 없이 몇 시간씩 머무르지 말 것, 유휴 정지 화면 송출을 중단할 것, 클라이언트 속도를 초당 100킬로비트 미만으로 유지할 것, 다른 사람과 공유하는 연결을 쓰기 전에 확인할 것을 요청했다. 정지 화면 하나가 네트워크 대역폭과 리플렉터 용량을 모두 소모할 수 있다고 경고했다. 이는 추상적인 프로토콜 권고가 아니라, 누군가가 공유 자원을 소유하고 있었기에 사용자에게 요청한 사항이었다.

Internet TV with CU-SeeMe와 함께 발행된 운영자 가이드는 계획 예시를 제시했다. 만족스러운 연결에 약 초당 80킬로비트, 리플렉터가 8명의 참가자를 수신하는 데 초당 640킬로비트, 스트림을 그룹에 재전송하는 데 초당 5.12메가비트였다. 이 수치는 측정된 벤치마크가 아니라 예시적인 추정이다. 그 가치는 이 설계의 곱셈 구조를 보여주는 데 있다. 리플렉터는 트래픽을 수신한 뒤 사본을 다시 보내야 했다. 가이드는 또한 Unix 호스트가 네트워크 연결성, 프로세서 용량, 지속 실행 능력 때문에 매력적이며, 참가자 및 발신자 한도를 위한 텍스트 파일 제어를 노출한다고 설명했다.

당대 사용자는 트래픽이 어디로 갈지 모른다면 초당 100킬로비트 미만으로 상한을 설정하도록 요청받았다. Cornell에서 유통된 1993년 5월 README는 한 리플렉터가 최대 6명의 참가자를 처리했다고 보고했다. 어느 수치도 보편적 상한을 확립하지는 않는다. 두 수치를 함께 보면, 사용 가능한 규모가 현지 장비, 네트워크 링크, 설정, 그리고 리플렉터를 유지하는 사람의 판단에 달려 있던 서비스임을 알 수 있다.

접근성은 작업을 없애는 대신 옮겼다

Cornell의 회고에 따르면 리플렉터의 탄생은 NSF 프로그램 책임자가 1992년 말 CU-SeeMe가 학생들을 위한 다자간 사용을 지원할 수 있는지 물은 뒤에 이루어졌다. Richard Cogger가 개념을 제안했고, John Lynn이 별도의 Unix 프로그램을 개발했으며, Scott Brim이 프로토콜 비평을 제공했다. 여러 미국 주와 런던의 학생을 연결한 Global Schoolhouse 회의가 성공을 거두었다. 이 역사는 리플렉터가 존재한 이유를 설명해준다. 실제 교육적 용도에는 지점 간 데모 그 이상이 필요했다.

Dorcey는 이 절충에 신중했다. 그는 팀이 복제와 배포를 넘어 사용자를 리플렉터에 의존하게 만들지 않으려 했다고 말하면서도, 리플렉터가 스트림을 수신자에 맞게 조정할 수 있음을 인정했다. 리플렉터는 실용적인 다리였고, 서버가 통신의 모든 부분을 통제해야 한다는 주장이 아니었다. 그럼에도 다리에는 호스트, 운영자, 충분한 용량, 그리고 이를 공유하는 사람들에 대한 규칙이 필요하다.

1995년 무렵 프로젝트는 프로토콜을 확장하고 오디오, 컬러 영상, 텍스트 채팅, 대역폭 관리 같은 기능을 추가했다. 이러한 추가는 서비스를 넓혔지만 중심 운영 질문을 없애지는 못했다. 저렴한 카메라는 단말을 감당할 수 있게 만들 수 있었지만, 그 방의 상류 대역폭, Unix 호스트, 유지보수 또는 모더레이션을 공급할 수는 없었다. CU-SeeMe는 하나의 장벽을 낮추고 다른 하나를 옮겼다.

기록은 리플렉터가 지나치게 비쌌다는 것, 모든 운영자가 공표된 예절을 강제했다는 것, 모든 사용자가 동등한 접근을 가졌다는 것을 보여주지 않는다. 다만 아키텍처의 거래를 이례적으로 구체적으로 보여준다. 클라이언트는 참여를 시도할 만큼 저렴하게 만들었고, 리플렉터는 작업을 공유되고 용량이 제한되며 사회적으로 가시적인 지점에 집중시킴으로써 그룹을 가능하게 했다.

출처