요약

  • RFC 9622에 따르면Sent는 메시지에서 파생된 데이터가 기반 프로토콜 스택 아래로 또는 그 스택을 통과하여 전달되었고 더 이상 Transport Services API의 책임이 아니게 되었음을 의미합니다.
  • 이 RFC는 데이터의 정확한 처분이 구현에 따라 달라진다는 점을 명시적으로 남겨둡니다. `Sent` 이벤트는 패킷이 송출되었다는, 피어가 수신했다는 또는 애플리케이션이 작업을 완료했다는 이식 가능한 주장이 아닙니다.

소프트웨어는 종종 수명 주기 라벨을 비즈니스 사실로 바꿔버립니다. 텔레메트리 화면은 “전송됨”이라고 표시하고, 감사 추적은 해당 조치를 종결하며, 호출자는 반환된 이벤트를 이야기의 끝으로 받아들입니다. 이 지름길은 로컬 소프트웨어가 저렴하게 기록할 수 있기 때문에 매력적입니다. 그러나 바로 이 지점에서 전송 경계가 결과로 위장하기 시작합니다.

Brian Trammell, Michael Welzl, Rolf Engelhardt, Gorry Fairhurst, Mirja Kühlewind, Colin Perkins, Paweł Tiesel, Tommy Pauly가 저술한 2025년 1월 Standards Track Transport Services API인 RFC 9622는 이에 대한 정확한 반례를 제공합니다. 이 문서의 `Sent` 이벤트는 메시지에서 파생된 데이터가 기반 프로토콜 스택 아래로 또는 그 스택을 통과하여 전달되었고 더 이상 API의 책임이 아니게 된 시점에 발생합니다. 문서는 곧바로 다음 사실을 일반화하는 것을 거부합니다. 그 시점에 데이터는 이미 전송되었거나, 네트워크 인터페이스 버퍼에 놓였거나, 커널 버퍼에 놓였거나, 그 밖의 구현별 위치를 차지하고 있을 수 있습니다.

이 표현은 낙관적인 보고로 수리해야 할 결함이 아닙니다. 이 API는 애플리케이션과 로컬 Transport Services System 사이에 위치합니다. 애플리케이션에 비동기적으로 요구 사항을 진술하고 로컬 이벤트를 수신하는 방법을 제공합니다. 원격 엔드포인트로부터의 프로토콜 확인 응답이 아닙니다. RFC 9621은 같은 권한 배분을 설계에 드러냅니다. 선택 속성은 요구 사항, 금지 사항 또는 선호도일 수 있으며, 후보 경로와 프로토콜 스택은 이용 가능한 정보, 시스템 정책, 구현 휴리스틱을 통해 선택됩니다.

이후의 이벤트들은 유용한 구분을 보존합니다. `Expired`는 선언된 Lifetime이 경과하기 전에 메시지가 전송되지 않았음을 나타내고, `SendError`는 과도한 크기, 기반 스택 실패, 호환되지 않는 속성 같은 로컬 오류를 식별합니다. Lifetime조차 힌트이지 늦은 메시지가 결코 전송되지 않으리라는 보장이 아닙니다. 우선순위도 마찬가지로 한정됩니다. RFC 9622는 상대적 우선순위, 완전히 송신자 로컬인 스케줄링까지 표현할 수 있도록 허용하지만, 그 표현이 어떻게 실현될지에 대해서는 아무것도 보장하지 않습니다.

실질적인 수신 체인은 더 깁니다. 애플리케이션 호출, 로컬 스택 인계, 장치와 인터페이스의 처분, 회선상 관측, 원격 전송 처리, 원격 애플리케이션 처리, 그리고 사용자나 운영자에게 중요한 효과까지 이어집니다. `Sent` 이벤트는 이 가운데 단 하나의 질문에 안전하게 답합니다. 나머지로부터 권위를 빌려서는 안 됩니다.

출처