Chapter 16
|
D.M.Z
CONTENT
PRE
NEXT
16.1 Usenet History
16.2 What is Usenet, Anyway?
16.3 How Does Usenet Handle News?
네트웍 뉴스의 아이디어는 1979년에 Tom Truscott과 Jim Ellis라는 두 명의 대학원생이, UN*X 유저들간의 정보교환을 위해 머신들을 연결하는데 UUCP를 사용하자는 생각에서 탄생하였다. 그들은 North Carolina에 세개의 머신으로 이루어진 소규모 네트웍을 셋업하였다.
초창기엔, 많은 쉘 스크립트 (이후 C로 다시 코딩되었다)에 의해 트래픽을 핸들하였으나, 그것은 사람들에게 릴리즈되지 않았다. 그것들은 재빨리 뉴스 소프트웨어의 첫번째 공개 릴리즈인 "A" news로 대체되었다.
"A" 뉴스는 하나의 그룹과 일일당 어느정도의 글 이상을 핸들하도록 디자인되지 않았다. 볼륨이 계속 커지자, Mark Horton과 Matt Glickman이 그것을 재코딩하여 "B" 릴리즈라 불렀다. Bnews의 첫번째 공개 릴리즈된 때는 1982년이며 버전은 2.1이었다. 그것은 여러기능이 추가되어 계속 확장되었고, 현재 버전은 Bnews 2.11이다. 그것은 마지막 공식 관리인이 INN으로 전향하는 바람에 서서히 구닥다리 신세가 되어가고 있다.
Geoff Collyer와 Henry Spencer는 나름대로 그것을 다시 써서 1987년에 릴리즈했는데, 이것을 릴리즈 "C" 또는 C News라 한다. 시간이 흘러감에따라 많은 패치가 C News에 가해졌는데, 그 중 가장 두드러진 것이 C News Performance Release이다. 많은 수의 그룹을 가진 사이트에서, 들어오는 글을 다른 호스트로 발송하는 역할을 하는 relaynews를 자주 호출하는데서 유발되는 오버헤드는 주목할만한 것이다. Performance Release는 백그라운드로 돌아가게 할수 있는 데몬 모드(daemon mode) 옵션를 relaynews에 추가하였다.
Performance Release는 현재 대부분의 리눅스 배포판에 포함된 C News 버전이다.
"C"에 이르기까지의 모든 news 릴리즈는, 비록 그것들이 다른 환경에서도 잘 사용될 수 있기도 하지만 UUCP 네트웍을 타겟으로 하고 있다. TCP/IP나 DECNet 등과 같은 네트웍 상에서의 효율적인 뉴스 전송은 새로은 체계를 요한다. 이것이 바로 1986년에 "Network News Transfer Protocol", 즉 NNTP가 소개된 이유이다. 그것은 네트웍 커넥션에 기반하여 인터랙티브하게 글을 전송하고 받아오는 몇가지 커맨드를 지정하고 있다.
Net에는, 사용가능한 몇가지 NNTP기반 어플리케이션이 있다. 그 중 하나가 Brian Barber와 Phil Lapsley의 nntpd 패키지로, 주로 로컬 네트웍상의 많은 호스트에게 newsreading 서비스를 제공하는데 사용할 수 있다. nntpd는 Bnews 또는 C News와 같은 뉴스 패키지에 NNTP 기능을 주도록 보조하게끔 디자인 되었다.
또다른 NNTP 패키지로는 INN (Internet News)가 있다. 그것은 단순히 front end의 역할만을 수행하는 것이 아니라, 그 자체로 뉴스 시스템이다. (원래 front end는 중간주파수 변환부나 증폭을 수행하는 부분을 말하는데, 여기서 쓰이긴 위의 nntpd가 단순히 Bnews나 C News와 같은 뉴스 시스템을 NNTP에 접목시키는 역할만을 하는데 빗댄것 같습니다 - 역자주) 그것은 공존하는 여러 NNTP링크들을 효율적으로 유지할 수 있는 복잡한 뉴스 릴레이 데목으로 구성되며, 많은 인터넷 사이트들이 채택하고 있는 뉴스 서버이다.
Usenet에관한 가장 놀랄만한 사실 중 하나는 그것이 어떠한 조직의 일부이지 않다는 것, 또는 그것엔 어떠한 종류의 중앙집중화된 네트웍 관리권한이 없다는 것이다. 사실, 그것은 기술적인 사항을 제외한 Usenet에 대한 지식의 일부이다. 당신은 그것이 무엇인지를 정의할 수 없고, 단지 그것이 무엇이 아니라는 것만을 말할 수 있다. 만약 Brenden Kehoe의 "Zen and the Art of the Internet" (온라인상에서 또는 Prentice-Hall을 통해 구할 수 있다. [Kehoe92]를 보라)을 손에 들고 있다면, Usenet의 특성이 아닌 것에 관한 재미있는 리스트를 볼 수 있을 것이다.
멍청하다는 소리를 각오하고 말한다면, Usenet을 Usenet 뉴스를 교환하는 별도의 사이트들의 협력체라고 정의할 수도 있다. Usenet 사이트가 되기위해서 당신이 해야하는 일은 단지, 또다른 Usenet 사이트를 찾고, 그것의 소유자와 관리자에게서 당신과 뉴스를 교환하자는 동의를 얻어야 한다. 다른 사이트에 뉴스를 공급하는 것을 일컬어 feeding한다고 하는데, 거기서 또 다른 Usenet 경험철학의 원칙이 생겨났다. "Get a feed and you're on it." ('두드려라 그럼 열릴것이다'를 패러디한 것 같습니다만 확실친 않군요 - 역자주)
Usenet 뉴스의 기본 유닛은 article로, 이는 유저가 쓰고 넷에 "포스팅"한 메시지이다. 뉴스 시스템이 그것을 다룰수 있게끔 그것 앞엔 관리상의 정보가, 즉 흔히 말하는 article header가 붙어 있다. 그것은 인터넷 메일 표준 RFC 822에서 규정한 메일 헤더 포맷과 아주 흡사하게, 콜론으로 끝나는 필드네임으로 시작해서 그 뒤에 필드 값이 붙는 형식의 여러 라인들로 구성된다.
article 하나 또는 그 이상의 뉴스 그룹 (newsgroup)으로 제출된다. 뉴스 그룹은 통상적인 주제(topic)에 관련한 포럼 정도로 생각하면 된다. 모든 뉴스 그룹은 계충 구조내에서 조직되며, 각 뉴스 그룹의 명칭은 계충 구조내에서 그것의 위치를 가리킨다. 이는 한 뉴스 그룹에관한 모든 것을 알기 쉽게 만든다. 예를 들어, 누구라도 comp.os.linux.announce라는 뉴스 그룹 네임을 보고, 그것이 리눅스라는 컴퓨터 운영체계에 관련된 공지에 사용됨을 알아볼 수 있다.
이들 article은 이 그룹에서의 뉴스를 운반하고자 하는 모든 Usenet site들간에 교환된다. 두 사이트가 뉴스를 교환 하는데 동의했을때, 그들은 그들이 원하는 어떠한 뉴스 그룹을 교환하건 자유로울 뿐 아니라, 심지어 그들의 로컬 뉴스 계층들을 추가할 수도 있다. 예를 들어 groucho.edu는 major news feed인 banyard.edu와 뉴스 링크를 맺고 있고, 또한 자신이 뉴스를 feed하는 minor site들과 몇개의 링크를 갖고 있다고 생각하자. 이제, GMU가 오직 sci, comp, rec 등의 소수의 메이저 계층을 운반하는데 비해, Banyard 대학은 모든 Usenet 그룹을 받게 될 것이다. 몇몇 하류 사이트, 이를테면 brewhq라는 UUCP 사이트는 아주 적은 뉴스 그룹만을 운반하길 원하는데, 그 이유는 네트웍이나 하드웨어적인 리소스가 부족하기 때문이다. 그 반면에, brewhq는 GMU에서 운반하지 않는 fj 계층에서 뉴스그룹을 받고자 한다. 그리하여, 그것은 모든 fj 그룹을 운반하고, 그것들을 brewhq에 feed해 주는 gargleblaster.com과의 또다른 링크을 유지한다. 그림 16.1은 뉴스의 흐름을 보여준다.
그림 16.1 : Groucho Marx University를 통한 Usenet News의 흐름
brewhq에서 뻗어나가는 화살의 레이블에관해선 약간의 설명을 해야겠다. 디폴트로, 그것은 로컬에서 생성되는 모든 뉴스가 groucho.edu로 보내지길 원하나, groucho.edu가 fj 그룹을 운반하지 않기 때문에 그들 그룹에서의 어떠한 메시지도 보내지 않는것이 적절하다. 따라서 brewhq로부터 GMU로의 feed에 all,!fj라는 레이블은 fj 아래의 것을 제외한 모든 그룹을 보낸다는 것을 의미한다.
16.3 How Does Usenet Handle News?
오늘날 유즈넷은 거대한 규모로 성장하였다. 넷 뉴스 전부를 운반하는 사이트들은 보통 하루에 61메가 바이트 정도를 전송한다. 물론 이는 파일을 주위로 돌이는 것보다 훨씬 더 많은 것을 필요로 한다. 그러므로 대부분의 UN*X 시스템이 Usenet News를 어떻게 핸들하는지에관해 살펴보도록 하자.
뉴스는 여러 전송 수단에의해 넷으로 배포된다. 과거의 전송 매개체는 UUCP이었으나, 오늘날의 main traffic은 인터넷 사이트에의해 운반된다. 이에 사용되는 알고리즘을 일컬어 flooding이라 한다: 각각의 사이트는 다른 사이트로의 몇개의 링크(news feed)를 갖고 있다. 로컬 뉴스 시스템에서 생성되거나 수신된 article은 그것들에게로 포워드되며, 만약 그것이 그 사이트에 이미 있는 것이라면, 포워딩된 그 article은 파기된다. 사이트에선 Path: 헤더필드를 살핌으로써 article이 경유해온 다른 모든 사이트들에관해 알 수 있다. 이 헤더는 article이 포워드된 모든 시스템의 리스트를 bang path notation 형식으로 갖고 있다.
article을 구별하고 중복이 있는지를 인식하기위해 Usenet article은 메시지 id를 가지고 있는데 (Message-Id: 헤더 필드에 지정된다), 이는 포스팅 사이트의 네임과 시리얼 넘버를 "<serial@site>"로 조합한다. 뉴스 시스템은 이 id를 처리하는 article마다, 새로 도착하는 모든 article에대해 체크하는 역할을 하는 history 파일에 로그한다.
양 사이트간의 흐름은 두가지 기준에의해 제한될 수 있다: 첫번째는, article에 (Distribution: 헤더필드내에) distribution을 지정됨으로써, 그것을 특정한 사이트 그룹으로 제한하는데 사용된다. 또한, 교환되는 뉴스그룹은 보내거나 받는 시스템 양쪽에의해 제한될 수 있다. 어떤 사이트로의 전송에대해 허용된 newsgroup과 distribution 세트는 보통 sys파일에 보존된다.
어느정도 수의 article들은 보다 상위체계로 향상될 필요가 있다. UUCP 네트웍에서는, 일정기간 article을 모았다가 이를 하나의 파일로 뭉치고 압축하여 리모트 사이트로 전송하는 방식이 자연스럽게 이루어진다. 이를 batching이라 한다.
위에서 말한 방식에서는 이미 전송한 바 있는 중복된 article이 먼저 전송될 수 있다. 그리하여 이에 대안으로 나온 것이 ihave/sendme 프로토콜인데, 이는 중복된 article의 전송을 막음으로써 넷의 bandwidth를 줄여준다. ihave/sendme프로토콜은, 모든 article을 batch파일에 집어넣는 대신, article의 메시지 id만을 조합하여 덩치 큰 "ihave" 메시지를 만들어 이를 리모트 사이트에 보낸다. 그러면 리모트 사이트는 이 메시지를 읽고 자신의 history파일과 비교한 후, 원하는 article의 리스트를 "sendme" 메시지에 넣어 돌려준다. 그러면 이 article만이 실제 전송되는 것이다.
물론, ihave/sendme는, 각각 여러개의 독립적인 feed에서 뉴스를 수신하고, 서로가 뉴스의 흐름을 감당할 수 있을만큼 충분히 자주 송신하는 두개의 대규모 사이트간에서나 통하는 것이다.
인터넷 상의 사이트들은 흔히 NNTP, 즉 Network News Transfer Protocol을 사용하는 TCP/IP기반의 소프트웨어에 의존한다. NNTP는 feed들간에 뉴스를 전송하고, 리모트호스트의 싱글 유저에게 Usenet 억세스를 제공한다.
NNTP는 세가지 방법으로 뉴스를 제공한다. 하나는 ihave/sendme의 실시간 버전으로 흔히 뉴스를 pushing한다고 부른다. 두번째는 뉴스를 pulling하는 것으로, 클라이언트가 주어진 뉴스그룹 또는 계층내에서, 특정일 이후에 서버 사이트에 도달한 article의 리스트를 요청하고, 자신의 history파일에 있지 않은 것들을 선택하는 것이다. 세번째 모드는 인터랙티브한 newsreading을 위한 것으로, 당신 또는 당신의 newsreader가 특정 그룹에서 article을 얻어올 수 있게하고, 불완전한 헤더 정보를 가지고도 article이 포스팅될 수 있게끔 한다.
각 사이트에서 뉴스는 /var/spool/news아래의 디렉토리 계층내에, 각 아티클은 별도의 파일에, 그리고 각 뉴스 그룹은 별개의 디렉토리에 보존된다. 디렉토리 네임은, 각 컴포넌트를 path 컴포넌트로 대칭시킨 뉴스그룹 네임으로 구성된다. 즉, comp.os.linux.misc의 article은 /var/spool/news/comp/os/linux/misc내에 보존된다. 뉴스 그룹내의 article엔, 그것이 도착한 순서대로 번호가 매겨져, 이 번호가 파일명이 된다. 현재 online인 article의 번호 범위는 active라는 파일에 보존되는데, 이는 동시에 당신사이트에서 알고있는 뉴스그룹에대한 리스트의 역할을 하기도 한다.
디스크 용량은 제한적인 리소스이다. 그 때문에, 일정 시간이 지난 후에 article을 버려야하는데, 이를 가리켜 expiring이라 부른다. 보통, 특정 그룹과 계층에서의 article은 그것들이 도착한 후부터 정해진 날짜에 expire된다. 이는 article 헤더에 있는 Expire: 필드에 expire되는 날짜를 지정함으로써 오버라이드 할 수 있다.
1. Introduction to Networking
2. Issues of TCP/IP Networking
3. Configuring the Networking Hardware
4. Setting up the Serial Hardware
5. Configuring TCP/IP Networking
6. Name Service and Resolver Configuration
7. Serial Line IP
8. The Point-to-Point Protocol
9. Various Network Applications
10. The Network Information System
11. The Network File System
12. Managing Taylor UUCP
13. Electronic Mail
14. Getting smail Up and Running
15. Sendmail+IDA
16. Netnews
17. C News
18. A Description of NNTP
19. Newsreader Configuration
A. A Null Printer Cable for PLIP
B. Sample smail Configuration Files
C. The GNU General Public License