요약

  • RFC 3940은 전송 중인 각NormObject에 전송과 복구를 위한 송신자 범위의 전송 번호를 부여했으며, 이는 전역적이거나 영구적인 콘텐츠 식별자가 아니었다.
  • 이 번호는 유한한 16비트 공간을 차지했고 반복될 수 있었다. 영구적인 명명은 애플리케이션이 정의한NORM_INFO또는 콘텐츠 자체에서 나와야 했다.

수신자에게 먼저 필요한 것은 간단한 답이었다

한 송신자가 하나의 큰 파일을 수천 명의 수신자에게 보내는 상황을 생각해 보자. 일부 경로에서 패킷이 사라지고, 서로 다른 수신자가 서로 다른 조각을 놓치며, 모든 수신자에게 모든 패킷에 대한 확인을 요구하면 네트워크가 감당할 수 있는 것보다 많은 피드백이 발생할 것이다. NACK 기반 신뢰성 멀티캐스트(NORM) 프로토콜은 이 문제를 반대 방향에서 접근했다. 수신자들은 전송이 제대로 되는 동안은 조용히 있고, 무엇인가 빠졌을 때만 복구를 요청한다. 순방향 오류 정정(FEC) 데이터는 빠진 원본 패킷을 하나하나 재현하지 않고도 손실을 복구할 수 있었다.

이 장치에는 작은 질문에 대한 실용적인 답이 필요했다. 이 세그먼트나 복구 데이터는 어느 전송 객체에 속한 것인가? 2004년 11월 실험 표준(Experimental)으로 발표된RFC 3940은object_transport_id를 제공했다. 송신자는 이 값을 단조 증가 방식으로 할당했고, 해당 객체의 전송과 복구 요청은 같은 값을 재사용했다. 프로토콜이 전달하는 송신자 식별자와 결합하면, 이 값은 해당 객체가 세션을 통해 이동하는 동안 하나의NormObject를 구별해 주었다.

전송 계층에서는 충분했다. 그러나 그것은 콘텐츠의 이름이 아니었다.

세 가지 컨테이너가 세 가지 의미를 정의하지는 않았다

NORM은 정적 메모리 데이터, 파일, 비유한 스트림이라는 세 가지 객체 유형을 제공했다. 이 분류조차 의미론적이라기보다 운영적인 성격이 강했다.NORM_OBJECT_DATA와NORM_OBJECT_FILE의 구분은 수신자가 메모리를 할당할지 비휘발성 저장소를 할당할지에 대한 단서일 뿐이었다. 그 저장 방식의 선택 외에는 프로토콜이 둘 다 유한한 콘텐츠 단위로 취급했다. 애플리케이션이 스트림 서비스를 정적 데이터에 사용하는 것도 가능했다.

따라서 이 라벨들은 수신자에게 어떤 객체가 “6월 장부”, “지도의 버전 7”, “서명된 긴급 공지”라는 것을 알려 주지 않았다. 전송을 어떻게 처리해야 하는지만 알려 주었다. 프로토콜 필드가 원래 설계되지 않은 기록으로 격상될 때마다 이 차이가 중요해진다. 저장 방식 힌트는 콘텐츠 클래스가 아니고, 복구 시퀀스는 출처(provenance)가 아니며, 성공적인 디코딩은 복구된 바이트가 데이터베이스가 기대하는 비즈니스 객체에 속한다는 증거가 아니다.

16비트는 여정을 표시했지 수명을 표시하지 않았다

객체 필드는 16비트였다. RFC 3940은 매우 길거나 무기한인 세션에서는 이 값이 반복될 수 있다고 명시했고, 수신자들이 비현실적으로 멀리 떨어진 값 주위에서 다시 동기화할 때 혼동을 막기에는 시퀀스 공간이 충분히 크다고 가정했다. 각 송신자는 자신의 시퀀스를 독립적으로 할당했다. 따라서 817 같은 맨 숫자는 거의 아무것도 말해 주지 못했다. 송신자, 송신자 인스턴스, 현재 세션 상태, 전송 시퀀스상의 시점이 모두 필요했다.

이 명세는 특히 직접적인 언어로 경계를 그었다. NORM 메시지 헤더는 데이터 콘텐츠의 전역적 또는 애플리케이션 수준 식별을 제공하지 않는다. 전송 식별자는 송신자가 해당 객체를 전송하거나 복구하는 동안에만 유효하다. 카운터의 순서가 유용했던 이유는 정확히 그것이 국소적이고 저렴했기 때문이다. 여기에 영구적인 의미를 부여했다면 그 효율성은 숨겨진 상태로 바뀌었을 것이다. 모든 캐시와 아카이브가 재사용된 값이 어느 송신자, 어느 세션, 카운터의 몇 번째 차례에 속하는지 기억해야 했을 것이다.

5년 뒤RFC 5740은 이 실험을 폐기하고 NORM을 표준화 트랙에 올렸다. 그러면서도 이 구분을 유지했고, 순환(wraparound)에 대한 서술을 단정적으로 만들었다. 장기 세션에서 이 필드는 반드시 순환하며 값을 반복한다는 것이다. 표준화는 전송 명세를 개선했을 뿐, 시퀀스 번호를 조용히 콘텐츠 식별자로 격상시키지는 않았다.

의미는 객체와 함께 이동할 수 있었다

NORM은 애플리케이션이 의미를 붙일 자리를 제공하기는 했다.NORM_INFO는NormObject와 연관된 선택적이고 애플리케이션이 정의한 컨텍스트를 담았다. MIME 타입이 제안된 용도 중 하나였다. 수신자는 이 작은 기록을 살펴보고 대용량 객체의 신뢰성 수신에 참여할지 판단할 수 있었다. INFO가 존재하면 데이터 메시지가 그 존재를 알리고, 놓친 수신자는 복구를 요청할 수 있었다.

그러나 INFO는 명명 기관이 아니었다. 그 의미는 규정되지 않았고, 선택 사항이었으며, 페이로드는 단일 송신자 세그먼트 안에 들어가야 했다. 원자적 설계는 컴팩트한 컨텍스트 기록을 빠르게 복구할 수 있게 해 주었지만, 그 기록에 전역 식별자, 다이제스트, 버전, 서명, 심지어 파일명이 들어 있다는 보장은 없었다. 애플리케이션은 그곳에 영구 식별을 넣거나 콘텐츠에 내장할 수 있었지만, 그 방식을 직접 선택하고 연관 관계를 유지해야 했다.

바로 여기서 신뢰성과 기억이 갈라진다. NORM은 전송 중에 같은 INFO 전송 ID가 대응하는 객체를 따라다니도록 보장할 수 있었다. 그러나 복구 창이 닫히면 전송 번호만 보관한 아카이브는 기록에서 가장 덜 영구적인 부분만 남긴 셈이었다. 그 번호가 나중에 다시 나타나도 프로토콜은 잘못한 것이 없다. 애플리케이션이 범위를 잊어버린 것이다.

완전히 복구된 객체조차 잘못된 객체일 수 있었다

프로토콜의 송신자 식별자와 16비트 객체 번호만으로 인덱싱된 수신자 캐시를 상상해 보라. 이 캐시는 연결이 끊기고 세션 세대 상태를 잃은 뒤, 카운터가 순환한 후에 돌아온다. 익숙한 키 아래 완전히 복구된 객체가 도착한다. 모든 세그먼트는 현재 전송 컨텍스트 안에서 유효하다. 그러나 캐시는 어제의 제목, 권한 규칙, 만료 규칙을 오늘의 바이트에 붙인다. 신뢰성이 잘못된 연관을 완성해 버린 것이다.

이 시나리오는 문서화된 사건이 아니라 경계로부터 도출한 추론이다. 그래서 근거가 계층을 유지해야 하는 이유를 보여 준다. 전송 근거는 어떤 송신자 인스턴스와 전송 중 객체가 세그먼트에 사용되었는지 확립할 수 있다. 콘텐츠 다이제스트는 애플리케이션이 제공한다면 바이트를 비교할 수 있다. 영구적인 애플리케이션 식별자는 전송을 버전화된 기록과 연결할 수 있다. 권한 부여와 게시 상태에는 또 다른 근거가 필요하다. 어떤 단일 계층도 전송이 성공했다는 이유만으로 다음 계층의 권위를 물려받지 않는다.

RFC 3940이 인터넷 역사에 기억되는 이유는 매력적인 지름길을 거부했기 때문이다. 분산 복구에 필요한 만큼의 식별을 만들고 그 지점에서 멈췄다. 프로토콜은 이동을 조율했고, 애플리케이션이 기억을 소유했다. 재사용 가능한 번호는 숨겨져야 할 결함이 아니었다. 설계에 새겨진 경고였다. 의미가 전송보다 오래 살아남아야 한다면, 의미에는 자기만의 이름이 필요하다.