요약

  • NNTPPOST는340으로 글 수령을 요청한 뒤, 점으로 끝나는 본문 전체가 도착해야만240또는441을 반환했습니다.
  • 이 최종 응답이 클라이언트에 도달하기 전에 연결이 끊어지면, 클라이언트 측면에서 성공적인 등록과 실패한 등록은 구분할 수 없게 됩니다.
  • 이후 시도에서 동일한 Message-ID를 유지하면 서버는 재시도를 같은 의도의 글로 다룰 수 있으며, 수락, 중재, 전파, 독자 가시성은 여전히 별개의 상태로 유지됩니다.

불확실한 구간은 마지막 점 이후에 시작되었다

포스팅 클라이언트가 모든 헤더, 본문의 모든 줄, 점 하나만 담긴 종료 행을 전부 전송했다고 상상해 보십시오. 등록 서버는 글을 검증하고 확정할 만한 재료를 이미 갖추고 있으며,240 Article received OK를 전송합니다. 바로 그 순간 연결이 끊어집니다. 서버는 이미 행동했지만, 클라이언트는 그것을 확인해 주는 어떤 근거도 갖지 못합니다.

본문 전송 이전의 명확한 실패라면 대응은 자명합니다. 그러나 여기서는 그렇지 않습니다. 글을 다시 보내면 거부된 포스트를 회복할 수도 있고, 이미 수락된 글의 사본을 만들 수도 있습니다. 아무것도 하지 않으면 중복을 피할 수도 있지만, 유일한 사본을 조용히 잃을 수도 있습니다. 사라진 응답이 이 구분을 지워 버렸습니다.

이것은 단순한 전송상의 불편이 아닙니다. 한쪽은 약속 경계를 넘었을 수도 있고 다른 쪽은 그것을 관찰할 수 없는 상황에서, 미확정 의도를 누가 소유하는가라는 문제입니다.

POST는 언제나 두 개의 응답을 가졌다

1986년에 발표된RFC 977은POST를 단일 요청이 아니라 대화로 정의했습니다. 서버는 클라이언트가 글을 보내야 함을 뜻하는340, 또는 포스팅이 불가함을 뜻하는440을 먼저 반환합니다. 클라이언트가 글 전체를 전달한 이후에야 서버는 결정적인 결과를 내놓습니다. 성공이면240, 실패면441입니다.

따라서 첫 번째 긍정 응답은 작업물의 보관이 아니라 작업 제출의 허가였습니다. 이 구분은 대화형 뉴스리더에게 중요했습니다. 사용자는 서버가 포스팅을 허용하는지 알기 전에 작성에 시간을 들일 수 있고, RFC 977은 읽기 전용 접근을 사용자에게 경고하기 위해 연결 인사말을 활용할 것까지 권고했습니다. 그러나 업로드가 시작되면, 이후의 응답만이 글이 포스팅 경계를 넘었다는 유일한 프로토콜상 근거가 됩니다.

RFC 3977은 같은 구조를 유지하면서 단계 간 혼동을 더 어렵게 만들었습니다.POST는 파이프라이닝할 수 없으며,340과440은 명령 자체에 대한 응답이고,240과441은 글과 그 종료 시퀀스 이후에 옵니다. 클라이언트는 본문에 대한 판정을 기다려야 시도를 완결된 것으로 다룰 수 있습니다.

수락은 가시성이 아니라 처리에 대한 약속이었다

RFC 3977은240에 의도적으로 미래지향적 의미를 부여했습니다. 예기치 못한 서버 오류가 없다면, 수락된 글은 추가 처리를 거친 후에라도 로컬에서 제공되거나 적절한 방식으로 계속 전달되어야 합니다. 서버가 글을 원하지 않는다면, 조용히 버리는 대신441로 거부해야 합니다.

이는 유용한 약속이지만, 나머지 Netnews 절차를 하나로 합쳐 주지는 않습니다. 규격은 클라이언트가STAT같은 수단으로 확인 없이는 글이 독자에게 제공된다고 가정해서는 안 된다고 경고합니다. 등록 대행 에이전트는 승인되지 않은 글을 중재자에게 전달해야 할 수 있고, 제공 에이전트는 아직 그것을 노출하지 않을 수 있습니다. 릴레이 에이전트들은 서로 다른 시점에 그것을 볼 수 있으며, 로컬 보존 정책은 로컬에 머뭅니다.

따라서 두 관찰은 서로 다른 질문에 답합니다.240은 포스팅 트랜잭션이 서버의 다음 처리 단계를 위해 명확히 수락되었다고 말합니다. 성공적인 읽기 조회는 특정 제공 뷰가 이제 그 글을 검색할 수 있다고 말합니다. 조회 실패는 특히 중재가 진행 중일 때 첫 번째 답을 뒤집을 수 없습니다.

잃어버린 응답은 가시성을 위험한 판정 기준으로 만들었다

RFC 3977은 이 실패를 직접 다룹니다. 세션이 클라이언트가 최종 응답을 수신하기 전에 끊긴다면, 긍정 응답이 이미 전송되고 유실되었을 수 있습니다. 이후 세션에서 클라이언트는 재전송 전에 포스팅이 성공했는지 확인하거나, 서버가 새 시도에 동일한 Message-ID를 부여하도록 보장해야 합니다.

규격은 안정적인 식별자를 선호합니다. 그 이유는 미묘합니다. 글이 아직 읽을 수 없는 상태일 수 있기 때문입니다. 중재가 바로 명시된 예입니다. '찾을 수 없음'을 거부의 증거로 다루는 클라이언트는, 첫 사본이 다른 단계에서 단지 대기 중인 동안 다시 제출할 수 있습니다.

그래서 프로토콜은 매력적이지만 거짓인 지름길을 거부합니다. 공개된 부재는 이전 등록 트랜잭션에 대한 신뢰할 수 있는 부정 증거가 아닙니다. 시스템에는 이 간격을 넘어서 살아남는 조정 키가 필요합니다.

하나의 이름이 재시도를 식별 가능하게 만들었다

RFC 3977의 부록은, 재전송을 준비하는 클라이언트는 이메일이나 Netnews 글에 대해 시도 전반에 걸쳐 내용이 동일하게 유지되는Message-ID헤더를 포함해야 한다고 말합니다. 서버는 같은 헤더 내용을 지닌 두 개의 POST된 글을 동일한 것으로 인식하고 동일한 메시지 식별자를 부여해야 합니다.

이것은 Message-ID의 전체 역사보다 좁은 범위입니다.RFC 5536은 이 필드를 전역적으로 고유한 식별자로 정의하고, Netnews가 고유성과 빠른 비교에 얼마나 크게 의존하는지 설명합니다.RFC 5537은 그 이유를 밝힙니다. 플러드 필 전파 방식에서는 같은 글이 여러 피어로부터 도착할 수 있으므로, 릴레이 및 제공 에이전트는 반복을 억제하기 위해 식별자 이력을 유지합니다.

잃어버린 POST의 경우, 이 식별자는 트랜잭션 영수증이 아닙니다. 첫 업로드가 성공했다는 증명도, 게시자의 인증도, 바이트 단위 무결성의 인증도 하지 않습니다. 그것은 단지 클라이언트의 불확실한 두 번째 시도가 자신을 새 글로 선언하지 못하게 할 뿐입니다. 서버와 하류의 이력 체계는 두 관찰을 하나의 의도된 대상에 맞출 수 있습니다.

그래서 모든 단락이 동일하더라도 재시도에 새 Message-ID를 생성하는 것은 운영상의 오류가 됩니다. 그것은 하나의 포스트에 대한 불확실성을, 각기 별도로 전파·중재·보존될 수 있는 두 개의 독립된 식별자로 바꾸어 버립니다.

등록과 읽기는 서로 다른 에이전트에 속했다

RFC 5537은 아키텍처 지도를 제공합니다. 포스팅 에이전트는 원시 글(proto-article)을 준비해 등록 대행 에이전트에 넘깁니다. 등록 대행 에이전트는 그것을 검증하고, 필요 시 요구 필드를 추가하고, 중재 대상 자료를 라우팅하며, 규격에 맞는 글을 릴레이 또는 제공 에이전트에 넘깁니다. 제공 에이전트는 독자가 글을 이용할 수 있게 합니다.

소프트웨어는 이 역할들을 하나의 서버 프로세스에 결합하는 경우가 많지만, 책임은 여전히 구분됩니다. 이 구분이 근거 해석을 보호합니다. 등록 인터페이스와의 성공적인 소켓 교환은 전역 전파의 측정이 아니며, 특정 제공 인터페이스에서의STAT실패는 등록 결정이 없었다는 증거가 아닙니다. 중재자의 대기열은 실패도, 공개 가용성도 아닙니다.

정상적으로는 등록이 한 번 일어납니다. RFC 5537은 동일한 원시 글을 여러 등록 지점으로 보내면 중복과 루프의 위험이 있다고 경고하며, 안정적인 Message-ID, Date, Injection-Date 필드가 서로 다른 경로가 하나의 글을 인식하도록 돕습니다. 잃어버린 응답 이후의 재시도는, 새 제출을 만드는 것보다 식별자를 보존하는 쪽이 더 안전한 또 하나의 지점입니다.

이력 파일은 피해를 없애는 대신 범위를 제한했다

중복 억제에는 한계가 있습니다. 이력 항목은 무한히 보존될 수 없고, 변형되거나 악의적인 식별자는 충돌을 일으킬 수 있으며, 서버마다 다른 정책을 적용할 수 있습니다. 실패는 등록 대행 에이전트가 식별자를 기록하기 전에, 또는 수락 후 모든 후속 상태가 영속화되기 전에 일어날 수 있습니다. 따라서 동일 ID 재시도는 정확히 한 번 보장(exactly-once)이 되지 않습니다.

그것이 바꾸는 것은 문제의 형태입니다. 안정적인 식별자가 없으면 운영자는 단지 비슷해 보이는 두 개의 글에 직면합니다. 안정적인 식별자가 있으면 운영자는 하나의 글에 관한 것이라고 주장하는 두 시도를 갖고, 이를 서버의 트랜잭션·등록·중재·릴레이·제공 기록과 대조할 수 있습니다.

IANA NNTP Parameters 레지스트리는POST를 표준 기능으로 등록하고 RFC 3977을 가리킵니다. 이 등록은 상호 운용 가능한 이름을 보존할 뿐, 특정 서버가 포스트를 수락하고 충분한 이력을 유지하며 글을 지금 노출한다는 뜻은 아닙니다. 그것들은 런타임 사실입니다.

오래 남는 설계 교훈은 소박하지만 강력합니다. 분산 프로토콜은 작업이 확정되었을 수 있지만 확인 응답이 사라진 구간을 언제나 없앨 수는 없습니다. 그러나 재시도가 다른 작업물이 되지 않도록 충분한 식별자를 보존할 수는 있습니다. NNTP는 글의 이름을 안정적으로 유지했고, 그렇게 함으로써 불확실한 응답이 글 자체를 복제하는 것을 막았습니다.

출처