같은 편지를 덜 옮긴 네트워크, 노드 지도에는 두 달의 기한

요약

• RFC 1429는 BITNET LISTSERV의 DISTRIBUTE가 토폴로지를 아는 범위에서 혼잡한 링크를 메시지 한 부로 건너고, 수신자 가까이에서 갈라 보내는 방식을 설명한다. 저자는 당시 하루 200만–600만 건의 메시지가 이를 거쳤다고 썼다.
• 운영자는 가까운 서버를 골라야 했고, 그 서버의 Master nodes 파일은 두 달보다 오래되지 않아야 했다. 하루 수신자가 1만 명을 넘을 예정이면 서버 관리자에게 먼저 허가를 구하라고 했다.

한 통의 본문이 여러 목적지로 가야 한다면, 복사본은 어디서 생겨야 할까? 1993년 2월 RFC 1429의 답은 혼잡한 링크를 지난 뒤, 수신자 무리에 가까운 곳이었다. LISTSERV에 메시지와 주소 목록을 한 번 넘기면 DISTRIBUTE 망이 가진 토폴로지 정보를 이용해 목적지를 묶었다. 저자 Eric Thomas는 그때 이 서비스가 하루 200만–600만 건을 운반한다고 기록했다.

이 설계에서 가장 비싼 착각은 서버 주소 하나를 보고 입구가 충분히 빠르다고 믿는 것이다. Thomas는 캘리포니아에서 시작해 주로 미국으로 갈 배포 작업을 스웨덴 서버에 보내는 어처구니없는 우회를 예로 들었다. 한 기관이 IP 쪽에는 T1 회선을 갖고 있어도 BITNET 쪽에는 9.6킬로비트 전용선만 갖고 있을 수 있었다. 어디에 접속하느냐가 전체 배포의 첫 병목을 정했다.

그다음에는 서버의 지도를 봐야 했다. RFC는 Master nodes 파일이 두 달보다 오래되지 않았는지 확인하라고 한다. 인력 부족 때문에 표를 갱신하지 않는 사이트도 있었다. DISTRIBUTE는 토폴로지 지식을 써서 중복 전송을 피하므로, 오래된 표는 경로를 묶는 판단부터 흔든다. 문서가 배포 효율의 주된 조건으로 토폴로지 정보의 질과 정확성을 든 이유다.

용량은 누군가의 책임이었다. 하루 1만 명 넘는 수신자에게 보낼 계획이라면 선택한 LISTSERV의 관리자에게 허가를 받고 작업량을 설명하라고 했다. 대학에 따라 큰 배포를 혼잡 시간에 제한하거나 여러 서버 중 알맞은 장비를 지정할 수 있었다. 공유망을 이용하는 사람은 다른 기관의 시간과 회선을 쓰고 있었다.

요청은 SMTP 메일로 쉽게 서버에 전달됐다. SMTP 봉투의 MAIL FROM은 요청이 LISTSERV에 닿지 못할 때 조치할 수 있는 사람을 가리켜야 했다. 요청 메일의 RFC822 From은 이후의 배달 문제와 반송을 받아야 했다. 거기에 목록의 투고 주소를 적으면 실패 알림이 다시 목록으로 들어가 순환할 수 있었다. 빠른 복제 기술도 실패 메시지의 주인을 대신 정해 주지는 않았다.

요청의 몸체에는 JOB 카드, DISTRIBUTE MAIL, BSMTP로 표시한 수신자들, 실제 본문이 차례로 들어갔다. DEBUG=YES는 전달하지 않고 예정 경로를 보여 주며, TRACE=YES는 전달하면서 보고한다. RFC의 실례에서는 세 명이 UGA를 거쳐 전달되고 두 명은 현지 SMTP에 맡겨졌다. 운영 모드의 ECHO=NO는 자원 사용 보고를 줄였다. 검사와 보고도 CPU와 대역폭을 쓰는 작업이었다.

저자가 제시한 당시 전형적 소요 시간은 연결이 양호한 BITNET 수신자에게 5–15분, 조직 가까운 기계로 보낼 수 있는 인터넷 수신자에게 5–20분이었다. 토폴로지 정보가 없는 목적지는 더 오래 걸릴 수 있었다. 숫자의 차이는 이 시스템의 속성이 드러난 자리다. 지도를 아는 곳에서는 한 부를 멀리 운반할 수 있었고, 지도를 모르는 곳에서는 그 지름길을 자신할 수 없었다.