다음을 통해 공유


이름 확인 모델

네임스페이스는 프로토콜을 연결하고 네트워크 서비스의 특성을 하나 이상의 친숙한 이름과 연결하는 일부 기능을 나타냅니다. 현재 인터넷의 DNS(도메인 이름 시스템), Active Directory Domain Services, 바인더리, Novell의 NetWare Directory Services(NDS) 및 X.500을 비롯한 많은 네임스페이스가 널리 사용되고 있습니다. 이러한 네임스페이스는 구성 및 구현 방법에 따라 크게 다릅니다. 일부 속성은 Winsock 이름 확인의 관점에서 이해하는 데 특히 중요합니다.

네임스페이스 유형

서비스를 등록할 수 있는 네임스페이스에는 세 가지 유형이 있습니다.

  • 동적
  • 정적
  • 영구적

동적 네임스페이스를 사용하면 서비스가 즉시 네임스페이스에 등록하고 클라이언트가 런타임에 사용 가능한 서비스를 검색할 수 있습니다. 동적 네임스페이스는 네트워크 서비스의 지속적인 가용성을 나타내기 위해 브로드캐스트를 자주 사용합니다. 동적 네임스페이스의 이전 예로는 NetWare 환경 내에서 사용되는 SAP(Service Advertising Protocol) 네임스페이스와 AppleTalk에서 사용하는 NBP(이름 바인딩 프로토콜) 네임스페이스가 있습니다. Windows에서 사용되는 PNRP(피어 이름 확인 프로토콜) 네임스페이스는 동적 네임스페이스의 최신 예입니다.

정적 네임스페이스는 네임스페이스를 만들 때 모든 서비스를 미리 등록해야 합니다. 정적 네임스페이스의 예로는 대부분의 TCP/IP 구현에서 사용하는 호스트, 프로토콜서비스 파일이 있습니다. Windows에서 이러한 파일은 일반적으로 C:\windows\system32\drivers\etc 폴더에 있습니다.

영구 네임스페이스를 사용하면 서비스가 즉시 네임스페이스에 등록할 수 있습니다. 그러나 동적 네임스페이스와 달리 영구 네임스페이스는 비휘발성 스토리지에 등록 정보를 유지하며, 서비스에서 제거를 요청할 때까지 유지됩니다. 영구 네임스페이스는 X.500 및 NDS(NetWare Directory Service)와 같은 디렉터리 서비스로 표시됩니다. 이러한 환경을 사용하면 서비스 속성을 추가, 삭제 및 수정할 수 있습니다. 또한 디렉터리 서비스 내의 서비스를 나타내는 서비스 개체에는 서비스와 연결된 다양한 특성이 있을 수 있습니다. 클라이언트 애플리케이션의 가장 중요한 특성은 서비스의 주소 지정 정보입니다. DNS는 영구 네임스페이스의 또 다른 예입니다. Windows 소켓을 사용하여 DNS 이름을 resolve 프로그래밍 방식의 방법이 있지만 Windows의 DNS 네임스페이스 공급자는 Winsock을 사용하여 새 DNS 이름 등록을 지원하지 않습니다. DNS 이름을 등록하려면 DNS 함수를 직접 사용해야 합니다. 자세한 내용은 DNS 참조를 참조하세요.

네임스페이스 조직

많은 네임스페이스가 계층적으로 정렬됩니다. X.500 및 NDS와 같은 일부에서는 무제한 중첩을 허용합니다. 다른 서비스를 단일 계층 구조 또는 그룹으로 결합할 수 있습니다. 이를 일반적으로 작업 그룹이라고 합니다. 쿼리를 생성할 때 검색이 시작되는 네임스페이스 계층 내에서 컨텍스트 지점을 설정해야 하는 경우가 많습니다.

네임스페이스 공급자 아키텍처

당연히 다양한 유형의 네임스페이스를 쿼리하고 네임스페이스 내에서 정보를 등록하는 데 사용되는 프로그래밍 인터페이스(지원되는 경우)는 크게 다릅니다. 네임스페이스 공급자는 Winsock 네임스페이스 SPI와 일부 기존 네임스페이스(로컬로 구현되거나 네트워크를 통해 액세스할 수 있음) 간에 매핑하는 방법을 알고 있는 로컬에 상주하는 소프트웨어입니다. 네임스페이스 공급자 아키텍처는 다음과 같습니다.

네임스페이스 공급자 아키텍처

지정된 네임스페이스(예: DNS)가 지정된 컴퓨터에 둘 이상의 네임스페이스 공급자를 설치할 수 있습니다.

위에서 설명한 것처럼 일반 용어 서비스는 클라이언트/서버 애플리케이션의 서버 절반을 나타냅니다. Winsock에서 서비스는 서비스 클래스와 연결되며, 특정 서비스의 각 instance 서비스 클래스 내에서 고유해야 하는 서비스 이름이 있습니다. 서비스 클래스의 예로는 FTP 서버, SQL Server, XYZ Corp. 직원 정보 서버 등이 있습니다. 예제에서 설명하려고 시도하면 일부 서비스 클래스는 잘 알려져 있지만 다른 서비스 클래스는 특정 세로 애플리케이션에 고유하고 특정합니다. 두 경우 모두 모든 서비스 클래스는 클래스 이름과 클래스 식별자 모두로 표시됩니다. 클래스 이름이 반드시 고유할 필요는 없지만 클래스 식별자는 이어야 합니다. GUID(Globally Unique Identifiers)는 서비스 클래스 식별자를 나타내는 데 사용됩니다. 잘 알려진 서비스의 경우 클래스 이름 및 GUID(클래스 식별자)가 미리 할당되었으며, 매크로를 사용하여 TCP 포트 번호(호스트 바이트 순서)와 해당 클래스 식별자 GUID 간에 변환할 수 있습니다. 다른 서비스의 경우 개발자는 클래스 이름을 선택하고 Uuidgen.exe 유틸리티를 사용하여 클래스 식별자에 대한 GUID를 생성합니다.

특정 서비스의 모든 인스턴스에서 공통적으로 유지되는 특성 집합을 설정할 수 있도록 서비스 클래스의 개념이 존재합니다. 이 특성 집합은 서비스 클래스가 Winsock에 정의될 때 제공되며 서비스 클래스 스키마 정보라고 합니다. 서비스가 설치되어 호스트 컴퓨터에 사용할 수 있게 되면 해당 서비스는 인스턴스화된 것으로 간주되며 해당 서비스 이름은 서비스의 특정 instance 네임스페이스에 알려질 수 있는 다른 인스턴스와 구별하는 데 사용됩니다.

서비스 클래스의 설치는 서비스를 활용할 수 있는 모든 클라이언트가 아니라 서비스가 실행되는 컴퓨터에서만 수행되어야 합니다. 가능한 경우 Ws2_32.dll 서비스 인스턴스화를 등록하거나 서비스 쿼리를 시작할 때 네임스페이스 공급자에게 서비스 클래스 스키마 정보를 제공합니다. 물론 Ws2_32.dll 이 정보 자체를 저장하지는 않지만 이 데이터를 제공하는 기능을 나타내는 네임스페이스 공급자에서 검색하려고 시도합니다. Ws2_32.dll 서비스 클래스 스키마를 제공할 수 있다는 보장은 없으므로 이 정보가 필요한 네임스페이스 공급자에는 네임스페이스별 수단을 통해 가져오는 대체 메커니즘이 있어야 합니다.

위에서 설명한 것처럼 인터넷은 호스트 중심 서비스 모델이라고 할 수 있는 것을 채택했습니다. 일반적으로 서비스의 전송 주소를 찾아야 하는 애플리케이션은 먼저 서비스를 호스트하는 것으로 알려진 특정 호스트의 주소를 resolve 합니다. 이 주소에 잘 알려진 포트 번호에 를 추가하여 전체 전송 주소를 만듭니다. 호스트 이름을 쉽게 확인할 수 있도록 특수 서비스 클래스 식별자가 사전 할당되었습니다(SVCID_HOSTNAME). SVCID_HOSTNAME 서비스 클래스로 지정하고 서비스 instance 이름의 호스트 이름을 지정하는 쿼리는 쿼리가 성공하면 호스트 주소 정보를 반환합니다.

Windows 소켓 2에서 프로토콜 독립적 애플리케이션은 전송 주소의 내부 세부 정보를 이해할 필요가 없습니다. 따라서 먼저 호스트 주소를 가져와 포트에 추가해야 하는 것은 문제가 됩니다. 이를 방지하기 위해 쿼리에는 특정 서비스의 잘 알려진 이름 및 서비스가 작동하는 프로토콜(예: TCP를 통한 FTP)이 포함될 수 있습니다. 이 경우 성공적인 쿼리는 지정된 호스트에서 지정된 서비스에 대한 전체 전송 주소를 반환하며 애플리케이션은 sockaddr 구조의 내부를 검사할 필요가 없습니다.

인터넷의 도메인 이름 시스템에는 서비스 클래스 스키마 정보를 저장하는 잘 정의된 수단이 없습니다. 결과적으로 Winsock용 DNS 네임스페이스 공급자는 서비스 클래스 GUID가 미리 할당된 잘 알려진 TCP/IP 서비스만 수용할 수 있습니다.

실제로 서비스 클래스 GUID가 전체 TCP 및 UDP 포트 집합에 대해 미리 할당되었으며 매크로를 사용하여 호스트 바이트 순서로 표현된 포트가 있는 TCP 또는 UDP 포트와 연결된 GUID를 검색할 수 있으므로 이는 심각한 제한이 아닙니다. 따라서 HTTP, FTP, Telnet, Whois 등과 같은 익숙한 모든 서비스 는 잘 지원됩니다.

서비스 클래스 예제를 계속 진행하면서 FTP 서비스의 instance 이름은 "alder.intel.com" 또는 "ftp.microsoft.com"일 수 있지만 XYZ Corp. Employee Info Server의 instance "XYZ Corp. Employee Info Server 버전 3.5"로 명명될 수 있습니다.

처음 두 경우에서 FTP용 서비스 클래스 GUID와 컴퓨터 이름(서비스 instance 이름으로 제공됨)의 조합은 원하는 서비스를 고유하게 식별합니다. 세 번째 경우 서비스 쿼리 시간에 서비스가 있는 호스트 이름을 검색할 수 있으므로 서비스 instance 이름에 호스트 이름을 포함할 필요가 없습니다.

DNS 참조

이름 확인 데이터 구조

프로토콜 독립적 이름 확인

등록 및 이름 확인

SOCKADDR

이름 확인 함수 요약