요약

  • RFC 3082는 사용자 에이전트가 반복적인 폴링 대신 서비스 변경 사항을 구독할 수 있게 하며, 디렉터리 에이전트(DA)가 있는 네트워크와 없는 네트워크에 서로 다른 통지 설계를 제시합니다.
  • DA가 사라지면, 이미 통지하도록 지정된 서비스 에이전트는 계속 전송할 수 있지만, 새로 등장한 에이전트는 구독 정보를 받지 못할 수 있습니다. 예전 통지가 계속 온다는 것만으로 신규 서비스에 대한 커버리지가 유지된다는 증거는 아닙니다.

쿼리는 피드가 아니다

서비스 로케이션 프로토콜(SLP)은 의도적인 비대칭 구조로 시작했습니다. 서비스 에이전트(SA)가 서비스를 광고하고, 사용자 에이전트(UA)가 필요할 때 물어보는 방식이었습니다. 이 덕분에 일상적인 검색은 수요 기반으로 유지되었습니다. 서비스가 나타나거나 사라질 때마다 로컬 뷰를 갱신하고 싶은 애플리케이션은 폴링을 해야 했습니다. 2001년 3월 실험적 프로토콜로 공표된 RFC 3082는 그런 클라이언트가 네트워크에 반복해서 묻지 않도록 변경 피드를 제안했습니다. 다만 이는 인터넷 표준이 되지는 못했습니다.

한 번 묻고 그다음엔 듣는다는 구분은 단순해 보이지만, 통지 시스템에는 또 다른 질문이 필요합니다. 새로 도착한 발신자에게 누군가 듣고 있다는 사실을 알려주는 주체는 누구인가? RFC 3082는 이 역할을 네트워크의 에이전트들에게 맡기되, DA가 존재하는지에 따라 두 가지 방식으로 나눕니다. 이 실패 사례가 유의미한 이유는 이 에이전트들이 동일한 상태를 서로 교환 가능한 복사본으로 갖고 있지 않기 때문입니다.

두 가지 토폴로지, 두 가지 통지 비용

DA가 없는 작은 네트워크에서는 SA가 IP 멀티캐스트로, 멀티캐스트를 쓸 수 없으면 IPv4 브로드캐스트로 등록과 등록 해제를 널리 알립니다. UA는 관심 없을 수도 있는 더 많은 서비스 유형과 스코프에 대한 통지를 받은 뒤 로컬에서 필터링합니다. 이는 새 SA에게 어떤 구독이 있는지 알려줄 브로커가 필요 없다는 장점이 있지만, 필터링 부담을 수신자에게 밀어넣고 멀티캐스트의 도달 범위와 스코프가 중요해집니다.

DA 기반의 더 큰 네트워크에서는 UA가 서비스 요청과 함께Subscribe확장을 보냅니다. DA는 요청된 서비스 유형과 스코프에 대한 멀티캐스트 그룹을 식별하는NotifyAt정보를 돌려줍니다. DA는 기존 SA들에게 새 구독을 알릴 수 있고, 일치하는 새 SA가 등록하면 그SrvAck에 같은NotifyAt지시를 담을 수 있습니다. DA는 또한 광고가 정상 종료 없이 만료될 때 등록 해제 통지를 발행합니다. 다만 대부분의 이벤트 광고는 여전히 SA가 발행하며, DA가 중앙 스트림으로 중계하는 것이 아닙니다.

이 설계는 작업을 분산하지만, 상태도 함께 분산합니다. DA는 구독을 추적하고, 기존 SA는 그룹 주소를 학습하며, UA는 그 그룹에 가입하고, 멀티캐스트 주소 할당에는 자체 스코프와 임대 기간이 있습니다. DA는 새로 본 구독을 광고하기 전 무작위 0~3초를 기다리고, 다른 DA에서 일치하는 광고를 들으면 자신의 광고를 억제합니다. 이는 중복 통지를 줄입니다. 하지만 UA의 구독 테이블을 복제하거나 여러 DA를 하나의 영속적 데이터베이스로 만들지는 않습니다.

무엇이 사라지고, 무엇이 계속되는가

10절은 이 부분 실패에 대해 이례적으로 명확합니다. DA가 예기치 않게 사라지면, 그 DA에 저장된 UA 구독 정보가 사라집니다. UA는 기존 SA들로부터 통지를 계속 받는데, 이는 그 SA들이 이미NotifyAt을 받았기 때문입니다. 하지만 새 SA는 다른 DA도 그 정보를 갖고 있지 않는 한 구독 사실을 알지 못합니다.

UA는 능동적으로 요청하기 전까지 대체 DA를 발견하지 못할 수 있습니다. 따라서 예전 DA가 사라진 시점과 UA가 다른 DA를 발견해 구독하는 시점 사이에 서비스가 등록될 수 있습니다. 이미 알려진 서비스들은 피드에 계속 나타날 수 있지만, 신규 서비스는 그곳에 나타나지 않을 수 있습니다. 눈에 보이는 스트림은 살아 있는 것처럼 보이면서도 커버리지에 빈틈이 있을 수 있습니다.

RFC 3082에는 예전 발신자들을 위한 복구 경로가 있습니다. 구독이 만료될 때까지 계속하되, 다른 DA가 없으면 만료를 무시하고 새 DA를 찾을 때까지 통지를 이어갑니다. 새 DA에 등록한 뒤 SA는SrvAck를 통해 UA가 구독을 갱신했는지 알 수 있습니다. 하지만 RFC 자체가 잔여 공백을 인정합니다. 재시작된 DA가 사용 가능해진 시점과 UA가 구독을 갱신하는 시점 사이에 시작된 SA에는 이 절차가 정보를 전달하지 못합니다. 모든 신규 서비스에 관심이 있는 UA는 자신의 스코프를 지원하는 새로 발견된 모든 DA에 구독해야 합니다. 구독 상태가 관련 DA에 존재하지 않는 한, 하드웨어 이중화만으로 이 커버리지가 확보되지 않습니다.

통지는 관찰이지 완결된 거래가 아니다

프로토콜의 나머지 부분도 기록을 분리해 유지해야 할 필요성을 강화합니다. 멀티캐스트 광고는 지수 백오프로 15초 동안 반복됩니다. 명시된 목적은 메시지가 전달될 확률을 높이는 것이지, 전달을 보장하거나 영속적인 이벤트 로그를 만드는 것이 아닙니다. 등록 통지가 UDP 패킷을 넘칠 수 있으며, 오버플로 비트는 UA에게 누락된 속성을 위해 나중에 SA나 DA에 쿼리가 필요할 수 있음을 알립니다. RFC 3082는 UA가 검증할 수 있는 인증 블록도 기술하지만, 메시지의 인증이 모든 수신자가 받았음, 엔드포인트가 여전히 도달 가능함, 또는 애플리케이션이 거래를 완료했음을 증명하지는 않습니다.

따라서 유용한 운영 체계는 다음과 같습니다. UA의 구독, DA에 저장된 스코프·유형 상태, SA에게 도달한NotifyAt지시, 멀티캐스트 그룹 가입, 이벤트 발행, 수신자가 실제 수신, 페이로드가 불완전할 경우의 후속 쿼리, 그리고 별개로 서비스 교환이 실제로 사용 가능함. RFC 3082는 일부 전환 단계에 대한 메커니즘을 규정하지만, 이를 하나의 종단 간 수신 확인으로 묶지 않습니다.

그래서 제목의 두 절은 서로 양립합니다. RFC 3082는 하나의 DA 장애가 네트워크를 침묵시킨다고 말하지 않습니다. 기존 SA는 계속할 수 있고, 대체 DA가 커버리지를 보존할 수 있습니다. 이 RFC가 말하는 것은 더 좁고 더 유용한 겁니다. 이미 통지받은 발신자에 대한 연속성은, 나중에 도착하는 발신자에 대한 검색 커버리지와 같지 않다는 것입니다. 폴링을 통지로 바꾸는 일은, 시스템이 누가 듣고 있는지 기억해야 하는 위치와 그 기억을 복원하는 복구 단계를 바꾸는 일입니다.

출처

프로토콜 및 역사 기록:RFC 3082,RFC Editor record,Datatracker history,RFC 2608: SLPv2,RFC 2119,RFC 2373,RFC 2730,RFC 2908. 편집적 관점으로만 사용되며 SLP 동작의 증거가 아닌 자료: Lu Heng,Running-Code Primacy및On Reality Layers.