요약

  • 각 Netnews 에이전트는 자신의 Path 식별자를 앞에 덧붙여, 기사를 이미 처리한 릴레이들의 궤적을 오른쪽에서 왼쪽으로 남겼다.
  • 발신자는 그 궤적에 이미 이름이 적힌 인접 릴레이로의 전송을 건너뛸 수 있어, 이웃의 별도 Message-ID 이력이 중복을 거부하기 전의 불필요한 되돌림 전송을 피할 수 있었다.
  • Path는 인증된 경로보다 의도적으로 약했다: 뱅 하나는 어떤 검증 주장도 하지 않았고, 현대의 진단 항목은 한정된 관찰을 기록했으며, 마지막not-for-mail항목은 애초에 릴레이가 아니었다.

낭비는 중복이 도달하기 전에 일어났다

세 대의 뉴스 서버가 삼각형으로 연결되어 있다고 생각해 보자. 한 기사가 A에 들어와 B로 이동한 뒤 C에 도달한다. 플러딩은 각 서버에게 수락한 기사를 관심 있는 이웃에게 제안하도록 요구한다. 이동 경로에 대한 기억이 없다면 B는 기사를 A에게 되돌려 보낼 수 있다. A는 Message-ID를 인식하고 반복을 버리므로 네트워크는 결국 수렴할 것이다. 그러나 네트워크는 반드시 버려질 바이트를 옮기는 데 비용을 지불한 것이다.

유즈넷은 이것이 서로 다른 두 가지 실패였기 때문에 두 가지 답을 발전시켰다. 이력 데이터베이스는 Message-ID로 논리적 기사를 기억하고, 돌아온 뒤에 반복된 식별자를 거부했다.Path필드는 이동 경로를 충분히 일찍 보이게 해서, 이미 이름이 적힌 릴레이로의 불필요한 제안이나 전송을 피하게 했다. 이력은 수렴을 보호했고, Path는 그 과정에서 회피 가능한 작업을 줄였다.

이 구분은RFC 1036에서 명시적이다. 이 문서의 전파 알고리즘은 Message-ID 이력만으로 루프를 멈추기에 충분하다고 한 뒤, Path를 추가적인 최적화로 기술한다. A가 기사를 B에게 보내면 A의 이름이 이미 필드에 있으므로 B는 기사를 즉시 되돌려 보내지 말아야 한다. 한 메커니즘은 “이 기사를 본 적 있다”고 판단하고, 다른 메커니즘은 “이 이웃이 이미 궤적에 있다”고 판단한다.

이 구분은 오해 섞인 유즈넷 역사를 막는다. Path는 서버에 기사 식별자가 없어서 발명된 것이 아니다. 또한 Message-ID 이력만으로 트래픽이 효율적이 되지도 않았다. 분산 시스템은 극한에서는 올바르면서 모든 경계에서 낭비적일 수 있다. Path는 최종 중복 검사 이전의 낭비를 공략했다.

가장 새로운 단계가 왼쪽에 나타났다

이 필드는 구두점, 가장 유명한 것은 느낌표로 구분된 이름들의 줄처럼 보였다. 그러나 그 시간 방향은 보통 문장과 반대였다. 각 수신 시스템은 자신을 왼쪽에 추가했다. 기사가A!X!Y!Z로 도착했다면 서버 B는 보이는 궤적을B!A!X!Y!Z로 바꾼다. 가장 새로운 관찰자가 맨 앞에 오고, 주입 끝은 오른쪽으로 밀려났다.

1983년에 발표된RFC 850은 이미 이 왼쪽 앞덧붙임 규칙을 기술하고 있었다. 이 문서는 여러 구분자를 허용하고 더 오래된 “뱅 경로” 세계와의 호환성을 유지했다. 이 값은 수동으로 라우팅된 메일 주소처럼 보일 수 있었지만, 문서는 이례적으로 직접적인 경고를 담았다. Path는 회신용이 아니며 우편 주소처럼 취급되어서는 안 된다는 것이다.

그 경고가 중요했던 이유는 유사성이 역사적이지 의미론적이지 않기 때문이다. 뉴스 기사와 메일 회신은 서로 다른 시스템을 거칠 수 있다. 릴레이 이름은 뉴스 피어에게는 의미가 있지만 메일 핸들러에게는 알려지지 않았을 수 있다. 보이는 순서가 우연히 반환 경로로 동작하더라도, 프로토콜은 그것에 그런 권한을 부여하지 않았다.

중간 역사 기록인RFC 1849는 나중에 운영적 그림을 더 좁혔다. 이 문서는 1990년대 초에 널리 회람된 초안에서 왔으며 2010년에 현재 구현 지침이 아닌 역사적 배경 자료로 출판되었다. 이 문서는 실용적 문법을!로 구분된 릴레이 이름과 뒤따르는 로컬 부분으로 줄였다. 릴레이들은 자신의 이름을 앞에 붙이고, 이름이 적힌 이웃에게 기사를 전달하지 말아야 했다.

같은 문서는 이것이 외견적 최적화가 아니었던 이유를 설명했다. Message-ID 이력은 보통 루프 도는 사본을 거부하지만, Path가 없다면 X에서 Y로 가는 평범한 링크가 거부되기 전에 수락된 모든 기사를 잘못된 방향으로 되돌려 보낼 수 있었다. 혼동된 릴레이 이름은 하나의 피드에서 트래픽을 두 배로 늘릴 수 있었다. 정확성은 살아남았지만 용량은 그렇지 않았다.

궤적에 속하지 않은 꼬리

가장 오른쪽 구성 요소는 미묘한 파싱 함정을 만들었다. 역사적 문법에서 그것은 발신자에 연관된 로컬 부분일 수 있었다. 반드시 방문 목록의 또 다른 릴레이인 것은 아니었다. 그것을 릴레이로 취급하면 우연히 같은 문자열을 쓰는 무관한 뉴스 서버로의 정당한 피드를 억제할 수 있었다.

현대 형식은 이 경계를 보이게 만든다.RFC 5536은path-list뒤에tail-entry가 오도록 정의한다. 꼬리는not-for-mail일 수 있으며, 이 구문은 Path에서 파생된 회신 주소의 긴 퇴각에서 물려받은 것이다. 이 구문은 라우팅 지시도, 오류도, 서버 이름도 아니다. 사실상 “옛 주소 모양 슬롯을 우편함으로 착각하지 말라”고 말하는 것이다.

그래서 범위가 데이터 모델에 속한다. 모든 뱅 구분 토큰을 하나의 무차별적인 “방문한 서버” 배열에 저장하는 파서는 프로토콜의 주장을 바꾼다. 같은 문자들이 path 목록 안, 진단 항목 안, 꼬리 안 어디에 있느냐에 따라 다른 역할을 가진다.

NNTP는 기사를 옮겼지만 그 흔적을 소유하지 않았다

유즈넷 뉴스는 원래 여러 메커니즘을 통해 이동했다.RFC 977은 1986년에 NNTP를 표준화하여 협력 호스트들이 TCP 같은 신뢰 가능한 스트림 위에서 뉴스를 배포, 검색, 게시할 수 있게 했다.RFC 3977은 2006년에 이를 더 완전한 프로토콜 계약으로 대체했다.

어느 변화도 Path를 TCP 연결 목록으로 만들지 않았다.RFC 5537의 현재 아키텍처는 Netnews 기사 처리가 특정 하위 전송 수단에 의존하지 않는다고 명시한다. Path는 주입, 릴레이, 서빙 구성 요소가 기사를 처리하는 동안 기사와 함께 있다. TCP 세션은 닫힐 수 있지만 기사와 그 흔적은 지속되고, 게이트웨이는 기사를 다른 매체를 통해 옮길 수 있으며, 여러 논리 구성 요소가 하나의 시스템을 공유할 수 있다.

따라서 이 필드는 IP 패킷이 통과한 라우터가 아니라 애플리케이션 계층 에이전트의 주장을 기록한다. 다음 패킷을 어디로 보낼지 네트워크에 지시하지 않는다. 예정된 발신자는 기사의 path 식별자들을 자신이 구성한 피드 관계와 결합한다. 운영자의 토폴로지와 피어 정책은 문자열 밖에 남는다.

뱅 하나가 검증된 인계를 의미하지는 않았다

RFC 5536과 RFC 5537은 서로 다른 등급의 지식을 받아들여 이 필드를 현대화했다. 처리를 수행하는 모든 뉴스 서버 구성 요소는 path 식별자를 사용하며, 이상적으로는 완전 정규화된 도메인 이름이나 관련 관리자가 고유성을 보장할 수 있는 다른 이름이다. 피어들은 그 식별자에 대한 공유된 이해가 필요하다. 그렇지 않으면 올바른 루프 검사가 동작할 수 없다.

왼쪽 에이전트가 바로 오른쪽의 path 식별자를 자신의 기준으로 검증했을 때, 문법은 연속된 두 개의 뱅을 보여줄 수 있다.!!진단은 인접 검사의 국소적 증거다. 단일!는 그런 주장을 하지 않는다. 같은 보증의 더 짧은 표기가 아니다.

다른 진단들은 불확실성을 지우지 않고 보존한다.POSTED는 주입을 표시하고 주입기가 본 출처를 기록할 수 있다.MISMATCH는 기사에 제시된 가장 왼쪽 식별자와 기대했던 출처의 식별자가 일치하지 않았다고 말한다.SEEN은 수신 구성 요소가 출처를 기록했지만 그것이 주장된 path 식별자임을 검증할 의사나 능력이 없었다고 말한다.

기대값은 수신 연결에서 나온다. 예를 들어 피어 인증 식별자나 IP 주소다. 이것은 각 진단을 하나의 신뢰 관계 안에서 한 관찰자가 하는 진술로 만든다. 불일치는 낡은 별칭, 이름 마이그레이션, 프록싱, 설정 오류 또는 기만에서 비롯될 수 있다. 문법은 분기를 기록할 뿐, 조사를 수행하지 않는다.

이중 뱅의 연쇄조차 종단간 서명이 아니다. 각 표시는 하나의 인접 관계와 한 에이전트의 만족에 관한 것이다. 이전의 모든 문자를 포괄하는 암호학적 약속도, 게시자 신원의 증명도, 이름이 적힌 시스템이 기사를 저장하거나 서빙했다는 약속도 없다. RFC 5537은 별도로, Path와 Injection-Info가 위조될 수 있으므로 릴레이는 신뢰하는 에이전트로부터만 기사를 받으라고 권한다.

릴레이가 여전히 결정을 내렸다

현대의 릴레이 규칙은 여전히 좁다. 수신 에이전트의 path 식별자나 알려진 별칭이 이미 path 목록에 나타나 있다면 기사를 그 수신자에게 보내지 말아야 한다. 이 검사는 꼬리와POSTED진단 이후에만 나타나는 식별자를 제외한다. 그런 범위 없이 단순 문자열 일치를 쓰면 잘못된 피드를 거부할 수 있다.

이 필드는 목록에 없는 모든 이웃에게 반드시 보내라고 강제하지도 않는다. 그룹과 Distribution 설정, 로컬 수락 정책, 피어 신뢰, 기사 유효성, 용량과 다른 제어가 여전히 적용된다. Path는 하나의 결정에 대한 부정적 증거를 제공한다. 이 예정된 피어는 이미 이동 경로에 등장한다는 것이다. 부재는 긍정적 허가가 아니다.

Message-ID 이력 데이터베이스는 별도의 방어선으로 남는다. 다른 경로로 도착한 같은 논리적 기사, 최적화를 무시하는 피어, 플러드 속의 평범한 수렴을 그것이 처리한다. 게이트웨이는 추가 예방책이 필요하다. 다른 매체로의 변환이 흔적과 식별자 속성을 버린 뒤 결과를 재주입할 수 있기 때문이다. Path가 유용한 이유는 모든 루프를 닫아서가 아니라 관할이 작기 때문이다.

변경 가능한 기록도 여전히 가치 있을 수 있었다

Path는 릴레이와 서빙 에이전트가 변경을 허용되는 몇 안 되는 기사 필드 중 하나다. 그 가변성이 무의미하게 만들지는 않는다. 그것은 필드를, 누가 어떤 연결 증거 아래 어떤 다음 홉 결정을 위해 어떤 구성 요소를 추가했는가에 따라 가치가 달라지는, 관리 인계에 인접한 작업 기록으로 만든다.

역사적 성취는 그 기록을 운영 중인 운영자에게 종속적으로 유지한 것이다. 중앙 서비스가 모든 기사에 대해 권위 있는 경로를 계산하지 않았다. 각 릴레이는 피어에게 식별자를 알리고, 받은 흔적을 검사하고, 자신이 구성한 관계를 적용하며, 한정된 관찰을 추가했다. 나쁜 식별자는 트래픽을 낭비하거나 억제할 수 있었지만, 필드가 저작, 저장, 글로벌 진실에 대한 권한을 얻지는 않았다.

RFC 근거는 이 설계와 명시된 실패 모드를 확립한다. 그러나 현재 어떤 서비스가 이 진단들을 사용하는지, 별칭이 어떻게 구성되어 있는지, 특정 Path가 정확한지, 한 서버가 기사를 수락한 후의 하류 결과가 무엇인지는 보여주지 않는다. 그 질문들은 실시간 피어, 세션, 전송, 이력, 저장 근거를 요구한다.