요약

  • reportAfter가 만기되면 RFC 3342는 과도 보고서를 생성한 뒤에도 데이터를 다음 릴레이로 계속 전달했습니다.
  • noLaterThan은 전달을 중단할 수 있었고,returnTrip은 최종 보고서의 귀환을 제한했습니다. 경보, 차단, 수신 확인, 응용 결과는 네 개의 서로 다른 사실이었습니다.

출발점은 즉시성과 최선 노력(best effort)을 제공하는 응용 데이터그램 서비스였습니다. 옵션이 없으면 릴레이가 이용 불가능할 때 조용한 손실이 발생할 수 있었습니다. RFC 3342의 옵션 패키지는 제어된 대기와 보고서를 추가했지만, “느림”, “정지”, “수신됨”, “성공”을 동시에 뜻하는 단일 상태를 만들지는 않았습니다.

이 절제는 주목할 만합니다. 많은 운영 체제에서 첫 빨간 표시등은 곧바로 판정이 됩니다. 경보 하나가 작업을 실패로 돌리고, 재시도를 유발하거나 보상 절차를 명령합니다. 여기서 프로토콜은 관찰 임계값이 전달에 영향을 주지 않는다고 명시적으로 말했습니다.

지시하지 않고 알리는 임계값

각 릴레이는dataTiming을 처리했기 때문에targetHop="all"로 모든 홉을 겨냥하고 옵션의 이해를 강제해야 했습니다. 데이터를 전달하기 전에 릴레이는 다음 릴레이를 찾고 연결을 수립하며 전송을 준비하는 데 로컬에서 소요된 시간을reportAfter에서 차감했습니다.

잔액이 0에 도달하면 릴레이는 그 값을 0으로 고정하고 보고 서비스를 호출한 뒤에도 데이터 항목을 전송했습니다. 마지막 홉에서는 같은 시한 내에 종단의ok가 없는 것 역시 보고서를 트리거했습니다.statusResponse는 트랜잭션 식별자를 담고 수신자를 과도 성공 코드인350에 매핑했습니다.

이 코드는 아무것도 취소하지 않았습니다. 알림 시한이 지났다는 사실만 증명했습니다. 메시지는 나중에 도착할 수 있었고, 그 도착이 경보를 거짓으로 만들지는 않았습니다. 반대로 정확한 경보가 손실이나 업무 실패를 증명하지도 않았습니다. 경보는 경로상의 한 지점에서 소모된 시간 간격을 서술했습니다.

경직된 시한은 동작을 바꿨다

noLaterThan은 다른 의미론을 가졌습니다. 이것 역시 로컬 처리 시간만큼 각 릴레이에서 감소했습니다. 그러나 다음 홉 이전에 0이나 음수가 되면 데이터는 전송되지 않았습니다.reportErrors가 설정된 경우 보고 서비스는 시간 초과 오류를 생성할 수 있었습니다.

마지막 홉에서 릴레이는 남은 예산 내에서 종단의 확인 응답을 기다렸습니다. 그 응답이 없으면 오류였습니다. 경계가 보입니다.reportAfter는 “여기서부터 알려주고 계속하라”고 말했고,noLaterThan은 “그 이상 진행하지 말라”고 말했습니다. 두 이벤트를 같은 상태로 분류하는 대시보드는 제어 정보를 파괴합니다.

정지조차 원인을 모두 설명하지 못했습니다. 예산은 로컬 처리, 느린 연결, 부재 중인 릴레이, 첨부되지 않은 종단, 혼잡에 의해 소모될 수 있었습니다. 검증 가능한 사실은 더 좁았습니다. 이 시도가 남은 한도 내에서 이 단계를 통과하지 못했다는 것뿐이었습니다.

보고서 역시 전달되어야 했다

수신자에게 성공적으로 전송된 후 0이 아닌returnTrip은 마지막 홉 보고서를 요구했습니다. 이 보고서는 발신자에게 마법처럼 나타나지 않았습니다. 그것은 새로운 APEX 연산으로 다시 출발했으며, 그dataTiming.noLaterThan은 초기returnTrip값과 같았습니다.

따라서 본 전달과 그 증거의 전달은 두 개의 여정이었습니다. 데이터는 도착할 수 있고, 보고서가 생성될 수 있으며, 귀환 도중 손실될 수 있었습니다. 시한이 만료되면 발신자는 보고서가 손실된 것으로 추정할 수 있었습니다. 그렇다고 데이터가 도착한 적 없다는 결론을 소급해서 내릴 수는 없었습니다.

정직한 대장은 초기 수락, 남은 경보 예산, 과도 보고서의 생성, 메시지의 계속 전달, 경직 예산, 정지 지점 또는 확인 응답, 최종 보고서의 생성, 그 귀환 예산, 수신, 응용이 관찰 가능한 결과를 별도로 유지할 것입니다. “상태”라는 단어 하나로 이 연대기를 담기에 부족합니다.

대기열, 홉 수, 교체

hold4Endpoint를 사용하면 릴레이는 수신 종단이 첨부되지 않은 한 데이터를 보관할 수 있었습니다. 상한이 없으면 대기열은 무한히 지속될 수 있었습니다. 문서는 서비스 거부 위험을 지적하고, 특히 짧은noLaterThan같은 관리 한도를 제안했습니다. 임시 저장은 결과에 대한 약속이 아니라 관리해야 할 노출이었습니다.

dataHopping은 루프를 탐지하기 위해 IP TTL에 가까운 카운터를 추가했습니다. 그것은 시간이 아니라 릴레이 수를 셉니다. 데이터는 시한을 다 소모하면서도 홉 수를 지킬 수 있고, 시간 예산 안에 머무르면서 빠르게 홉을 소모할 수도 있었습니다. 여기서도 두 한도는 같은 증거를 만들지 않았습니다.

마지막으로attachOverride는 같은 종단에 대해 새 응용이 이전 응용을 대체하도록 허용했습니다. 늦게 도착한 응답의 소유권 문제는 RFC 3340의 메커니즘과 별도의 문서에 속합니다. 다만 시간 보고서가 그것만으로 여전히 액션을 소유한 응용을 특정하지 않는다는 사실만 확인해 줍니다.

역사가 말할 수 있는 것

RFC 3342는 2002년 7월 표준화 경로에서 발표되었습니다. 오늘날 Historic으로 분류되어 있으며 RFC Editor의 errata 검색에는 해당하는 정오표가 없습니다. 2012년 7월 29일자 IETF 이력은 “IETF가 파악한 한” RFC 3340~3343의 구현은 배포된 적이 없고 그 기능은 RFC 6120과 RFC 6121에 따라 광범위하게 배포된 XMPP가 제공한다고 기록합니다.

이 기록이 타임아웃이 그러한 궤적을 초래했다는 것을 증명하지는 않습니다. 인시던트도, 측정도, 구현 판단도 제공하지 않습니다. 문서는 또한dataTiming이 사적 토폴로지를 드러낼 수 있다고 경고했습니다. 따라서 관리자는 이를 도메인 경계로 제한할 수 있었습니다. 관찰 가능성에는 비용이 있었고, 그 정밀성 때문에 무한한 권한을 얻지도 못했습니다.

오래 남는 교훈은 세 가지 질문에 담겨 있습니다. 어느 시한은 관찰만 하는가? 어느 시한은 실제로 처리를 바꾸는가? 어느 시한이 증거의 귀환을 보호하는가? 이 답들이 서로 구별되는 한, 경보는 결과를 찬탈하지 않고도 유용할 수 있습니다.

출처