요약

  • RFC 3421은 SLP 클라이언트가 서버에 일치하는 서비스 URL의 정렬을 요청하고 선정된 개수만 반환받을 수 있게 했지만, 첫 번째 URL이 먼저 나오는 것은 요청된 키와 서버가 저장한 속성 기준에서만 그러했다.
  • 응답은 서로 다른 수량을 구분해 유지했다.m은 전체 일치 개수였고,n은 반환되는 부분 집합을 제한했으며, 누락되거나 일치하지 않는 값은 NULL로 처리되었고, Sort와 Select 단계의 순서가 최종 승자를 바꿀 수 있었다.

연결이 존재하기 전에 승자가 나타났다

서비스 검색은 살아 있는 무언가를 찾는 과정처럼 들린다. 클라이언트는 가까운 프린터, 부하가 적은 서버, 특정 기능을 갖춘 장치를 원한다. 그러나 디렉터리는 보통 광고와 속성을 근거로 답한다. TCP 연결, 애플리케이션 교환, 현재 성능 측정이 일어나기 전에도 그 기록들을 비교할 수 있다.

바로 이 차이가 2002년 11월에 실험적(Experimental) 확장으로 공개된 Service Location Protocol의RFC 3421을 이끌었다. SLP는 이미 User Agent가 Directory Agent나 Service Agent에 서비스를 요청하는 것을 허용했다. 이 확장은 두 가지 변환을 추가했다. Sort는 일치하는 URL을 명명된 속성으로 정렬할 수 있고, Select는 반환되는 URL 수를 제한할 수 있다.

이 메커니즘이 유용했던 것은 완전한 응답이 좁은 링크에서 낭비가 될 수 있기 때문이었다. 동시에 쉬운 과잉 주장도 낳았다. “반환된 목록의 첫 번째”는 “가장 좋은 서비스”처럼 들린다. RFC의 실제 근거는 더 좁았다. 하나의 서버가 자신이 보유한 속성에 이러한 선언된 비교 규칙을 적용한 뒤 이 항목이 첫 번째로 왔다는 것뿐이다.

Select는 전체를 부분 집합과 구분해 두었다

클라이언트는Select(n)을 보내 최대n개의 URL 항목을 요청한다. 이를 지원하는 서버는Select(m)을 반환하는데,m은 전체 일치 개수다.n이m보다 작으면 앞의n개 항목만 이동한다.n이m이상이면 모든 일치 항목이 이동한다.

특수한 경우Select(0)은 이 구분을 특히 명확하게 만든다. 클라이언트는 일치 URL을 하나도 받지 않으면서 일치 개수를 받는다. 개수와 목록은 서로 다른 사실이다.m을 “m개의 엔드포인트를 검사했다”로 바꾸는 모니터링 시스템은 틀린 말이 된다. 클라이언트는 아무것도 검사하지 않았을 수 있고, 디렉터리 자체도 실시간 프로브가 아니라 등록 기록을 근거로 작업하고 있을 수 있기 때문이다.

마찬가지로 세 개의 URL이 담긴 응답은 일치가 세 개뿐이었다는 증거가 아니다. 요청자가n을 세로 설정했다는 것만 증명할 수 있다. 전체 개수, 반환된 부분 집합, 이후 시도된 후보, 성공한 서비스는 서로 다른 필드를 필요로 한다.

Sort는 모델을 정의했지 측정을 정의하지 않았다

Sort 확장은 순서가 있는 키 목록을 담는다. 각 키는 속성 이름을 지정하고, 문자열 또는 정수 비교를 선언하고, 오름차순 또는 내림차순을 선택하며, 정수 기준 값을 포함할 수 있다. 목록에서 앞선 키가 더 높은 우선순위를 갖는다.

기준 값 정렬은 시사점이 크다. 요청이 속도가 12에 가장 가까워야 한다고 하면, 서버는 저장된 각 값과 12 사이의 절대 거리를 계산한다. 속도가 12인 URL은 10, 15, 8보다 먼저 정렬된다. 이는 기록된 속성에 대한 올바른 수학적 결과이며, 새로운 속도 측정이 아니다.

문자열 비교는 SLP의 규칙에 따른 어휘적 비교이고, 정수 비교는 참조된 매칭 규칙을 따른다. 같은 키를 반복해도 두 번째 표를 만들지는 않는다. 첫 번째 등장만 계산된다. 이러한 세부 사항은 순위를 재현 가능하게 만들면서 그 정책을 노출한다. 요청이 무엇이 중요한지, 타입이 무엇인지, 높은 값과 낮은 값 중 무엇이 이기는지를 결정한다.

결측 데이터는 사라지지 않았다

실제 디렉터리에는 불완전하고 불일치한 등록 기록이 담겨 있다. RFC 3421은 누락된 정렬 키에 NULL 값을 부여하고, NULL은 모든 유효한 값보다 뒤에 정렬된다. 요청된 정수 정렬과 일치하지 않는 값 역시 NULL로 처리된다. 다중 값을 가진 속성의 경우 가장 작은 값이 사용된다.

이러한 규칙은 구현이 조용히 즉흑적으로 처리하는 것을 막지만, 결과를 낳는다. 부하 속성이 없는 서비스는 실제 부하와 관계없이 유효한 부하 값을 가진 모든 서비스 뒤로 밀린다. 여러 부하 값을 광고하는 서비스는 평균, 최댓값, 최신값이 아니라 정렬을 위해 가장 작은 값으로 대표된다. 잘못 입력된 타입의 값은 그 비교에서는 부재가 된다.

따라서 이 순서화된 목록은 데이터 형태에 대한 보고서이기도 하다. 낮은 순위는 유효한 높은 부하를 의미할 수도 있고, 누락된 필드나 타입 불일치를 의미할 수도 있다. 기반이 되는 속성과 처리 기록이 남아 있지 않으면 응답만으로는 그 원인들을 구분할 수 없다.

순서에 따라 생존하는 후보가 달라졌다

RFC 3421은 복수의 Select와 Sort 확장이 등장 순서대로 처리되도록 요구한다. 속도로 정렬하고, 셋을 Select하고, 그 셋을 부하로 정렬하고, 하나를 Select하면 결과는 저장된 데이터 기준 가장 빠른 셋 중 부하가 가장 적은 서비스다.

앞의 두 연산을 뒤집으면 후보 모집단이 달라진다. 정렬 전에 셋을 Select하면 속도를 검토하기 전에 일부 서비스가 버려질 수 있다. 전체 집합을 부하로 정렬하고 하나를 선택하는 것은 또 다른 질문에 답한다.

이는 우연한 구현 세부 사항이 아니었다. 확장 체인은 작은 질의 계획이었다. 모든 Select 단계는 이후 단계가 볼 수 있는 것을 바꿨다. 최종 승자는 순서화된 계획 없이는 해석할 수 없다. 데이터베이스 결과를 이전 LIMIT를 무시한 채 마지막ORDER BY만으로 재구성할 수 없는 것과 같다.

기능 광고가 사용에 앞섰다

이 확장들을 지원하는 Directory Agent나 Service Agent는select-enabled및/또는sort-enabled를 광고한다. User Agent는 해당 요청을 보내기 전에 이 속성들을 확인해야 한다. 서버가 확장을 지원하지 않거나 요청된 정렬을 수행할 수 없으면OPTION_NOT_UNDERSTOOD를 반환한다.

기능 광고는 선언된 지원에 대한 증거이지, 모든 속성의 신선도에 대한 증거가 아니다. 성공적인 영(0) 오류 코드는 요청이 처리되고 정렬이 수행되었다는 것을 확립한다. 그러나 부하 값이 최근에 측정되었는지, 그 작성자가 신뢰되는지, 모든 적격 서비스가 등록되었는지, 선택된 URL이 응답할지는 확립하지 않는다.

RFC는 정렬이 best effort라고도 명시한다. 이 표현은 문서화된 규칙을 지우는 것이 아니라 신뢰를 좁혀야 하는 신호다. 운영자는 요청, 기능, 응답 코드, 키 순서, 반환된 순서를 검증할 수 있다. 그러나 디렉터리 스냅숏과 그 밖의 세계에 대해서는 별도의 증거가 여전히 필요하다.

필수 확장 공간이 보편적 배포를 의미하지는 않았다

IANA는 Select와 Sort에 SLP의 필수 구현 확장용으로 예약된 범위에서0x4002와0x4003식별자를 할당했다. 그 레지스트리 위치는 확장 프레임워크를 설명할 뿐이다. 실험적 RFC를 모든 과거 또는 현재의 SLP 제품이 올바르게 배포했다는 증거로 바꾸지는 못한다.

기능 키워드는 운영상으로 여전히 중요하다. 문서적 지위, 번호 할당, 광고된 지원, 처리된 요청, 성공적인 서비스 사용은 서로 다른 층이다. 하나를 나머지 모두의 대용품으로 취급하면 추적 가능한 체인이 전설로 변한다.

순위에는 두 번째 여정이 필요했다

검색 이후에도 클라이언트에게는 할 일이 남는다. URL을 해석하거나 파싱하고, 연결을 열고, 애플리케이션 프로토콜을 협상하고, 피어를 인증하고, 요청된 작업을 수행할 수 있다. 어느 단계에서든 실패가 발생해도 디렉터리의 정렬 연산이 소급적으로 거짓이 되는 것은 아니다. 정렬과 서비스 결과의 범위가 달랐다는 것을 보여줄 뿐이다.

작은 실험적 확장 안에 이것이 바로 지속되는 역사다. RFC 3421은 대역폭을 절약했을 뿐 아니라, “가장 좋다”에 내재된 정책, 즉 속성 작성자, 스냅숏 시점, 데이터 타입, 비교 방향, NULL 규칙, 키 우선순위, 잘라내기 순서를 노출했다. 이 입력들이 한번 보이면 최상위 결과는 전지적이 되지 않으면서도 유용해질 수 있다.

출처와 한계

1차 기록은RFC Editor HTML,일반 텍스트,RFC Editor 정보 페이지,IETF Datatracker 문서 페이지, 그이력과참고문헌, 그리고RFC Editor 정오표 검색에서 확인할 수 있다.

SLP 맥락은 원본RFC 2165, SLPv2RFC 2608, 서비스 템플릿RFC 2609,RFC 2614의 API,RFC 2891의 LDAP 정렬 모델, 속성 목록 확장RFC 3059, IPv6 사용RFC 3111, 벤더 확장RFC 3224, 메시 향상RFC 3528, 원격 검색RFC 3832, 그리고IANA Service Location 템플릿 레지스트리에서 온다. 명세와 운영 증거 사이의 분석적 구분은 Lu Heng의running code as primary와minimum initial specification에세이를 따른다.

이 출처들은 프로토콜 규칙과 문서적 역사를 확립한다. 배포, 등록 완전성, 속성 신선도, 현재 지연 시간, 현재 부하, 서비스 성공 여부는 측정하지 않는다.