요약

  • Project Athena는 성장하는 워크스테이션 네트워크 전반에서 짧고 시간에 민감한 알림을 전달하기 위해 Zephyr를 설계했습니다. 로컬 브로드캐스트와 일반 이메일은 각각 서로 다른 방식으로 한계에 부딪혔습니다.
  • Zephyr는 인증된 신원, 로그인 위치, 공개 여부 선택, 주제 구독, 메시지 전달을 별개의 상태로 유지했으며, 어느 것도 그 사람이 자리에 있는지 또는 알림을 읽었는지를 증명하지 못했습니다.

첫 번째 문제는 메시지를 화면에 띄우는 방법이 아니었습니다. 컴퓨팅이 하나의 공유 기계에서 벗어난 뒤, 정확한 사람에게 닿게 하는 방법이었습니다. Project Athena의 1987–88년 계획은 수많은 네트워크화된 워크스테이션으로 이동하던 학술 환경을 보여줍니다. 한 호스트의 프로세스는 파일 서버 사용자들에게 곧 종료된다는 사실을 알려야 할 수 있고, 프린트 서비스는 완료된 작업을 보고해야 하며, 조교는 수업 전체에 닿고 싶어할 수 있습니다. 전통적인 메일은 내용을 보존할 수 있었지만 지연과 이름이 적힌 수신자 목록을 강요했습니다. 네트워크 브로드캐스트는 빨랐지만 로컬 네트워크에 국한되었고, 소수 사용자만을 위한 트래픽을 모든 기계가 검사해야 한다면 낭비였습니다. Zephyr 설계자들은 두 한계를 분명하게 명명했습니다. 이메일은 느리고 번거로웠고, 브로드캐스트는 일시적이며 확장되지 않는다는 것이었습니다.

그리하여 Zephyr는 여러 종류의 통신 아래 깔리는 알림 서비스로 규정되었습니다. 1988년 USENIX 논문은 기본 전송 계층과, 구독과 사용자 위치를 위한 상위 계층을 설명했습니다. 1989년 6월 5일자 기술 계획에 이르면 워크스테이션에는 전형적으로 HostManager(zhm)가, 각 로그인에는 WindowGram 클라이언트(zwgc)가 있었고, 여러 Zephyr 서버가 등록, 라우팅, 상태를 담당했습니다. 알림은 클라이언트 데이터와 별도의 라우팅 필드를 담았습니다. 서버는 헤더를 사용해 수신자를 찾았고, 메시지 본문을 해석할 필요가 없었습니다. 이 분리 덕분에 파일 서버는 이미 아는 사용자들에게 보낼 수 있었고, 고정된 청중이 없는 서비스는 클래스 아래 알림을 발행하고 클라이언트가 구독하게 할 수 있었습니다.

구독은 캠퍼스 전체의 외침이 아니라 명시적인 상태였습니다. 서버는 클래스, 인스턴스, 수신자로 이루어진 튜플을 기록했습니다. 사용자의 클라이언트가 구독을 요청할 수 있었고, 그 튜플과 일치하는 알림은 관심 있는 클라이언트에만 라우팅될 수 있었습니다. 직접zwrite는 수신자 신원을 사용했습니다. Kerberos는 Zephyr ID로 사용되는 인증된 주체를 공급했으므로, 시스템은 인증된 계정과 메시지에 입력된 문자열을 구분할 수 있었습니다. 그러나 인증은 '이 요청을 보낸 신원이 누구인가'에 답했을 뿐입니다. 인증 자체가 모든 발신자에게 모든 수신자의 위치를 알아내거나 방해할 권한을 부여하지는 않았습니다. 설계는 접근 통제, 사용자 공개 설정, 특권 있는 긴급 알림을 별도로 기술했습니다.

접속 정보에는 저마다 한계가 있었습니다. Zephyr는 사용자의 로그인과 위치를 등록해, 발신자가 세션이 놓인 워크스테이션을 알지 못해도 알림이 활성 클라이언트를 찾도록 했습니다. 설계자들은 운영자에게 위치 데이터베이스를 완벽한 실시간 명부로 읽지 말라고 경고했습니다. 기록은 인증된 로그인이 보고되었음을 보여줄 뿐이며, 워크스테이션 크래시는 로그아웃 메시지를 막고 오래된 상태를 남길 수 있었습니다. 반대 추론도 실패했습니다. 보이는 위치가 없다고 해서 그 사람이 로그인한 적이 없다고 증명되지 않았는데, 사용자가 위치를 공개하지 않기로 선택할 수 있었기 때문입니다. 시스템은 재부팅 중과 서버가 호스트가 응답하지 않음을 발견했을 때 오래된 워크스테이션 기록을 지우려 했습니다. 그런 복구는 나쁜 상태를 줄였지만, 분산 서비스를 결함 없는 증인으로 만들지는 못했습니다.

Zephyr의 공개 설정은 이 구분을 사용자에게 드러냈습니다. 1989년 계획은none,opstaff,realm-visible,realm-announced,net-visible,net-announced의 여섯 설정을 나열했습니다. 위치 조회와 로그인/로그아웃 공지는 하나의 스위치가 아니었습니다. 한 사람은 각 로그인을 공지하지 않으면서 Kerberos 영역 안에서는 보일 수 있었고, 더 넓은 가시성과 공지는 별도로 선택할 수 있었습니다. MIT의 1993년 사용자 안내서는hide를 Zephyr를 끄는 것과 구분해 설명하기도 했습니다. 위치를 숨기는 것이 다른 사람들이 알림을 보내는 것을 막지는 않았다는 것입니다. 이것은 보편적인 '나에게 연락하지 마시오' 스위치보다 좁은 종류의 통제이며, 안내서는 그 경계를 숨기지 않고 문서화합니다.

전송 신뢰성도 또 하나의 별개 문제였습니다. Zephyr는 UDP를 사용하고, 애플리케이션이 원하는 곳에 확인 응답 수준을 추가했습니다. 설계자들은 중복, 재정렬, 손실, 흐름 제어 부재를 경고했습니다.zwrite예제가 보장한 것은 메시지가 전송되었다는 것이지, 도착했거나 정확히 한 번 도착했다는 것이 아니었습니다. 서버 확인 응답, 수신 클라이언트의 확인 응답, 사람이 WindowGram을 읽는 것은 서로 다른 사건이었습니다. 덕분에 Zephyr는 빠른 조정에 유용했지만, 전송 영수증이 동의, 주의, 완료된 작업을 안전하게 대신할 수는 없었습니다.

1993년까지 MIT의 사용자 안내서는 일대일 및 그룹 Zephyrgram을 아테나의 보통 도구로 기술했고, 1996년 연구는 Zephyr Help Instance를 동기 지원 채널로 검토했습니다. 이것들은 MIT에서의 사용을 보여주는 증거이지, 한 캠퍼스 서비스가 인스턴트 메시징의 보편적 모델이 되었다는 증명이 아닙니다. Project Athena의 시스템은 그 자체의 워크스테이션, Kerberos 영역, 운영 스태프에 의해 형성되었습니다. 그 역사가 더 유익한 지점은 그것이 그은 경계입니다. 신원은 라우팅을 지탱할 수 있고, 로그인은 위치 기록을 지탱할 수 있으며, 구독은 한 부류의 알림에 대한 관심을 표현할 수 있지만, 권한, 도달 가능성, 사람의 주의는 별개의 문제로 남았다는 것입니다.

출처