요약

  • 초기 LDAP에서MessageID는 하나의 세션에서 아직 진행 중인 요청 사이에서만 고유하면 되었습니다. 한 작업에 속한 모든 항목 응답, 참조 응답과 최종 결과가 그 ID를 반복했고, 덕분에 비동기 응답이 교차하더라도 서로 구별할 수 없는 상태가 되지 않았습니다.
  • Abandon은 이 식별자의 한계를 드러냈습니다. 봉투에는 자신의 ID가 들어가고 페이로드에는 대상 ID가 지정되었지만, 요청도 성공적으로 중단된 검색도 완료 응답을 돌려주지 않았습니다. RFC 3909는 이후 결과를 받는 Cancel 작업을 추가해 결과가 필요한 애플리케이션을 지원했습니다.
  • 페이징 검색은 각 페이지마다 새로운 메시지 ID를 사용하고 계속을 위한 불투명 쿠키를 사용했습니다. ID는 로컬 작업을 가리킬 뿐, 상대를 인증하거나, 지속적인 질의를 명명하거나, 쓰기가 되돌려졌음을 증명하지 않았습니다.

검색은 하나의 응답이 아니었습니다

LDAP의 '경량'이라는 말은 모든 작업이 질문 하나와 답 하나로 끝난다는 뜻이 아니었습니다. 이 프로토콜은 X.500 모델을 기반으로 만들어진 디렉터리 서비스에 접근하는 더 저렴한 방법으로 설계되었습니다. 클라이언트가 하위 트리를 요청하면 유용한 답변에는 수백 개의 디렉터리 항목, 다른 네이밍 컨텍스트에 대한 참조, 그 뒤에야 터미널 결과가 포함될 수 있었습니다.

1993년 7월에 발표된RFC 1487은 모든 작업을 공통의LDAPMessage봉투 안에 넣었습니다. 봉투의 유일한 공유 필드는messageID였고, 이 정수는 같은 LDAP 세션에서 아직 진행 중인 다른 요청들의 ID와 달라야 했습니다. 서버는 그 값을 해당 요청에 대응하는 모든 응답 봉투에 복사했습니다.

이 표현은 이 숫자에 단순한 패킷 카운터보다 더 흥미로운 역할을 부여했습니다. 검색은 0개 이상의 항목 응답과 하나의 최종 결과를 돌려주며, 이 모두는 하나의 작업에 속합니다. 만약 응답마다 번호가 바뀌었다면, 클라이언트는 어떤 항목과 터미널 상태가 하나의 결과 흐름을 이루는지 알아내기 위해 다른 방법이 필요했을 것입니다.

이 번호는 디렉터리 객체를 설명하지 않았습니다. 그 역할은 고유 이름(distinguished name)이 맡았습니다. 작업의 의미를 설명하지도 않았습니다. 그것은 프로토콜 작업 태그의 몫이었습니다. 이 번호는 진행 중인 요청과 그 요청을 위해 생성된 메시지 사이의 결합을 제공했습니다.

교차가 범위를 드러냈습니다

1995년 LDAP 규격인RFC 1777은 동기 동작에 대한 요구가 없다고 명시했습니다. 여러 작업의 요청과 응답은 어떤 순서로든 교환될 수 있었습니다. 클라이언트는 넓은 검색이 아직 항목을 반환하는 동안 빠른 비교 작업을 보낼 수 있었고, 서버는 검색이 최종 결과에 도달하기 전에 비교 결과를 먼저 답할 수 있었습니다.

그 결과로 나오는 와이어 순서는 다음과 같을 수 있습니다: 검색 41, 비교 42, 항목 41, 비교 결과 42, 또 다른 항목 41, 최종 검색 결과 41. TCP는 신뢰할 수 있는 순서가 보장된 바이트를 제공했지만, 인코딩된 각 메시지가 어떤 애플리케이션 작업에 속하는지는 알려주지 않았습니다. 이 역할을MessageID가 수행했습니다.

이것이 역사적 계약이 세션 로컬이었던 이유입니다. ID는 그 세션의 다른 진행 중인 요청들과만 달라야 했습니다. 다른 클라이언트도 41을 사용할 수 있고, 같은 클라이언트도 이전 작업이 명확히 끝난 후에는 41을 다시 사용할 수 있었습니다. 비교 대상이 LDAP 세션과 작업 수명이었으므로 이 두 경우 모두 충돌이 생기지 않습니다.

RFC 2251은 1997년 이 메커니즘을 LDAPv3로 가져왔습니다. 정수를 2^31−1로 한정하고, 클라이언트가 보통 카운터를 증가시킨다는 점을 언급하며, 최종 응답 전에 ID를 재사용하는 것을 금지했습니다. 또한 검색 응답에 서로 다른 형식을 부여했는데,SearchResultEntry와SearchResultReference는 어느 순서로든 도착할 수 있고 그 뒤에 성공이나 오류를 담은 하나의SearchResultDone이 옵니다.

그래서 터미널 응답은 두 가지 역할을 했습니다. 결과 코드는 검색이 어떻게 끝났는지 말해주고, 그 도착 자체가 서버가 더 이상 그 작업의 ID를 필요로 하지 않는다는 통상적인 증거가 되었습니다.

0은 질문 없는 서버 발화를 위해 따로 마련되었습니다

2006년 개정은 LDAPv3를 재정리했습니다.RFC 4510은 새 규격 집합이 RFC 2251을 대체한 경위를 기록하며,RFC 4511에는 수정된 프로토콜 규칙이 담겨 있습니다.

RFC 4511은 요청 ID가 명시적으로 0이 아니어야 한다고 규정했습니다. 0은 서버가 먼저 보내는 요청하지 않은 통지, 즉 클라이언트 요청에 답하는 것이 아닌 서버 기원의 예외적 메시지를 위해 예약되었습니다. 그래서 연결 해제 통지(Notice of Disconnection)는 메시지 ID 0으로 도착하더라도 작업 0의 응답 흐름으로 오해되지 않았습니다.

이것은 전역 네임스페이스 할당이 아니라 로컬에서 강제되는 구분이었습니다. 양수 ID는 클라이언트가 시작한 진행 중인 작업에 속했고, 0은 그 상관관계 바깥의 정의된 서버 발화 부류를 신호했습니다. 작업의 의미는 여전히 프로토콜 작업 태그와 통지 객체 식별자가 제공했습니다.

재사용은 경과 시간이 아니라 서비스 수명에 묶여 있었습니다. 클라이언트는 서버가 더 이상 이전 요청을 처리하지 않는다고 판단할 수 있을 때만 ID를 재사용할 수 있었습니다. 예를 들어 최종 응답 이후나 그 뒤의 Bind가 완료된 경우입니다. 타임아웃은 세션을 닫거나 애플리케이션 상태를 조정할 근거가 될 수 있지만, 침묵만으로 서버의 상태 테이블을 다시 쓰지는 못했습니다.

Abandon은 두 개의 번호를 필요로 하면서도 결과를 알릴 수 없었습니다

LDAP의 원래 탈출구인 Abandon은 권한 범위에 대한 간결한 교훈입니다. Abandon 작업 자체가 LDAP 요청이므로 그 봉투에는 새로운MessageID가 담깁니다. 그 페이로드도MessageID인데, 클라이언트가 멈추려는 이전 작업의 ID입니다. 한 번호는 Abandon 요청 자체를 작업으로서 상호연관시키고, 다른 번호는 대상을 지정합니다.

Abandon에 대한 응답은 없습니다. RFC 4511에 따르면 서버는 대상을 중단할 수 있습니다. 대상이 이미 결과를 내보내고 있는 검색이라면, 서버는 이후 항목 응답 전송을 멈추고SearchResultDone을 보내서는 안 됩니다. 그럼에도 클라이언트는 이미 전송 중인 결과를 견뎌야 하고, 일부 작업은 아예 중단될 수 없습니다.

이 침묵은 의도적이지만 모호합니다. 이는 클라이언트가 더 이상 결과를 원하지 않을 때 흔히 쓰는 요청에 또 하나의 응답 교환을 추가하지 않습니다. 동시에 클라이언트가 성공한 중단과 아직 끝나지 않은 작업을 구별할 수 없다는 뜻이기도 합니다. 공유 ID는 어떤 작업이 대상이었는지는 정확히 알려주지만, 서버가 그에 대해 무엇을 했는지는 증명하지 못합니다.

RFC 2251은 재사용 규칙에 이 불확실성을 반영했습니다. 나중 요청에 대한 응답이 도착할 때까지는 Abandon 요청의 ID나 대상 ID 중 어느 것도 재활용하지 마십시오. 그 이후 응답은 Abandon에 대한 확인이 아니라, 서버가 연결에서 충돌 위험의 일종을 줄일 만큼 진행했다는 단순한 증거일 뿐입니다.

Cancel은 결과를 추가했을 뿐, 기존 신호를 강한 것처럼 꾸미지 않았습니다

2004년에 발표된RFC 3909는 결과 표시가 필요한 애플리케이션을 위한 LDAP Cancel 확장 작업을 정의했습니다. 이는 Abandon의 의미를 바꾸지 않았고, 별도의 메커니즘을 도입했습니다.

Cancel 요청에는 자체 봉투MessageID가 있고, 진행 중인 작업을 지정하는cancelID를 담습니다. 취소가 성공하면 서버는 성공적인 Cancel 응답을 돌려주고 대상 작업은 결과 코드canceled로 끝납니다. 다른 결과들은 서버가 모르는 대상, 취소할 수 없는 작업, 너무 늦게 도착한 요청을 구별합니다.

tooLate사례가 중요합니다. RFC 3909는 이미 기반 데이터 저장소에 커밋된 갱신을 예로 듭니다. 완벽한 상관관계가 롤백 권한을 만들어주지는 않습니다. 취소 ID가 의도한 갱신을 정확히 가리키더라도, 유일하게 정직한 결과는 그 되돌릴 수 없는 효과가 이미 경계를 넘어갔다는 것입니다.

Cancel은 대상으로 삼을 수 있는 작업도 제한합니다. Bind, StartTLS, Unbind, Abandon과 Cancel 자신은 취소 대상이 아닙니다. 이 작업들은 통상적인 작업 ID가 의미를 갖는 연결과 보안 컨텍스트를 만들고, 바꾸고, 해체합니다. 진행 중인 한 작업이 그 컨텍스트를 함부로 지울 수 있게 두면, 상관관계 키가 원래 설계되지 않은 통제 권한으로 변질됩니다.

새 페이지에는 새 ID가 필요했습니다

검색 페이징은 이를 가장 명확히 반증하는 사례입니다.RFC 2696은 서버가 결과 한 페이지와 불투명 쿠키를SearchResultDone안에 담아 돌려주게 합니다. 다음 페이지를 요청할 때 클라이언트는 검색 값을 반복하되messageID를 바꾸고, 최신 쿠키를 제공하며, 페이지 크기를 바꿀 수 있습니다.

다음 페이지는 새로운 LDAP 작업입니다. 쿠키는 서버 측 계속 상태를 이 작업들 사이에서 옮겨 담습니다. 오래된 쿠키는 사용할 수 없을 수 있고, 빈 쿠키는 시퀀스가 끝났다는 뜻입니다. Abandon은 진행 중인 한 페이지 요청을 멈출 수 있지만 쿠키를 무효로 만들 수 있으며, 페이징 시퀀스를 깨끗하게 끝내려면 크기 0과 최신 쿠키로 새 검색 요청을 보냅니다.

이 구분 덕분에 하나의 편리한 정수가 신화적인 내구성을 얻는 일이 막힙니다. 메시지 ID는 “이 세션의 어느 진행 중인 작업이 이 메시지를 만들었는가?”에 답합니다. 쿠키는 “이 이후 작업이 서버가 보유한 결과 위치 중 어디에서 이어갈 수 있는가?”에 답합니다. 디렉터리 항목의 고유 이름은 또 다른 질문에 답합니다.

자료들은 규칙을 확립할 뿐 현재 동작을 측정하지 않습니다

역사적 연쇄는RFC 1487,RFC 1777,RFC 2251,RFC 2696,RFC 3909,RFC 4510,RFC 4511로 닫혀 있습니다. 이 문서들은 프로토콜 형식, 규범적 경계, 개정 이력을 확립합니다. 그러나 배포 현황을 측정하거나, 구현을 인증하거나, 포착된 작업의 결과를 증명하지는 않습니다.

LDAP의 작은 정수가 살아남은 이유는 권한이 좁았기 때문입니다. 이 ID는 수신자가 실제로 검사할 수 있는 상태와 메시지를 연결했습니다. 애플리케이션이 더 많은 것—완료, 취소, 계속, 인증 또는 권한 부여—을 필요로 할 때마다 프로토콜은 서로 다른 증거를 요구했습니다.