엔드포인트 찾기
서버 프로그램은 클라이언트 요청에 대한 엔드포인트를 수신 대기합니다. 엔드포인트 문자열의 구문은 사용하는 프로토콜 시퀀스에 따라 달라집니다. 예를 들어 TCP/IP에 대한 엔드포인트는 포트 번호이고 명명된 파이프의 엔드포인트 구문은 유효한 파이프 이름입니다.
엔드포인트에는 잘 알려진 엔드포인트와 동적의 두 가지 유형이 있습니다. 프로그램에서 사용하는 엔드포인트 유형을 선택하면 분산 애플리케이션 또는 런타임 라이브러리가 엔드포인트를 지정하는지 여부가 결정됩니다.
이 섹션에서는 엔드포인트에 대해 설명하고 엔드포인트를 찾는 방법에 대한 정보를 제공합니다. 다음 topics 구성됩니다.
참고
정적 엔드포인트와 잘 알려진 엔드포인트라는 용어는 동일하며 서로 바꿔서 사용됩니다.
클라이언트 애플리케이션에서 엔드포인트 맵을 사용하여 서버 프로그램이 현재 실행 중인지 여부를 확인할 수 있습니다. 클라이언트는 RpcMgmtInqIfIds, RpcMgmtEpEltInqBegin 및 RpcMgmtEpEltInqDone 을 호출하여 서버가 엔드포인트 맵에 필요한 특정 인터페이스를 등록했는지 확인할 수 있습니다.
잘 알려진 엔드포인트 사용
잘 알려진 엔드포인트는 서버 프로그램이 실행할 때마다 사용하는 미리 할당된 엔드포인트입니다. 서버는 항상 특정 엔드포인트를 수신 대기하므로 클라이언트는 항상 연결을 시도합니다. 잘 알려진 엔드포인트는 일반적으로 전송 프로토콜을 담당하는 기관에서 할당합니다. 서버 호스트 컴퓨터에는 사용 가능한 엔드포인트 수가 한정되어 있으므로 애플리케이션 개발자는 잘 알려진 엔드포인트를 사용하지 않는 것이 좋습니다. 동적 엔드포인트의 또 다른 장점은 시스템의 장기 관리 및 유지 관리를 간소화한다는 것입니다.
분산 애플리케이션은 문자열에서 잘 알려진 엔드포인트를 지정하고 해당 문자열을 RpcServerUseProtseqEp 함수에 매개 변수로 전달할 수 있습니다. 또는 엔드포인트 문자열이 [ 엔드포인트] 인터페이스 특성의 일부로 IDL 파일 인터페이스 헤더에 나타날 수 있습니다.
두 가지 방법을 사용하여 잘 알려진 엔드포인트를 구현할 수 있습니다.
- 문자열 바인딩의 모든 정보 지정
- 이름 서비스 데이터베이스에 잘 알려진 엔드포인트 저장
바인딩을 개발할 때 분산 애플리케이션에 바인딩을 설정하는 데 필요한 모든 정보를 작성할 수 있습니다. 클라이언트는 문자열에서 직접 잘 알려진 엔드포인트 를 지정하고 RpcStringBindingCompose 를 호출하여 모든 바인딩 정보가 포함된 문자열을 만들고 이 문자열 을 RpcBindingFromStringBindingBinding 함수에 제공하여 핸들을 가져올 수 있습니다. 클라이언트와 서버는 잘 알려진 엔드포인트를 사용하기 위해 하드 코딩되거나 엔드포인트 정보가 명령줄, 데이터 파일, 구성 파일 또는 IDL 파일에서 나오도록 작성할 수 있습니다.
클라이언트 애플리케이션은 이름 서비스 데이터베이스에서 잘 알려진 엔드포인트 정보를 쿼리할 수도 있습니다.
동적 엔드포인트 사용
특정 서버 및 특정 프로토콜 시퀀스에 대한 엔드포인트 수는 일반적으로 제한됩니다. 예를 들어 TCP /IP를 사용하여 RPC 네트워크 통신이 발생함을 나타내는 ncacn_ip_tcp 프로토콜 시퀀스를 사용하는 경우 제한된 수의 포트만 사용할 수 있습니다(대부분의 시스템에는 1025~5000 범위만 열려 있음). RPC 런타임 라이브러리를 사용하면 필요에 따라 엔드포인트를 동적으로 할당할 수 있습니다. 가능한 인터페이스 UUID 수는 거의 무제한이므로 인터페이스 UUID를 사용하여 호출을 지시하면 확장 및 유연성이 더 높아집니다.
기본적으로 RPC 런타임 라이브러리 함수는 이름 서비스 데이터베이스를 쿼리할 때 엔드포인트 정보를 검색합니다. 엔드포인트가 동적이면 이름 서비스 데이터베이스에 엔드포인트 정보가 포함되지 않습니다. 그러나 쿼리는 클라이언트 프로그램에 서버 이름을 제공합니다. 그런 다음 서버의 엔드포인트 맵을 검색할 수 있습니다.
클라이언트가 동적 엔드포인트를 사용하여 원격 프로시저 호출을 수행해야 하는 경우 기본 설정 방법은 부분적으로 바인딩된 바인딩 핸들에서 호출하는 것입니다. RPC 런타임은 엔드포인트를 투명하게 확인합니다. 이 메서드는 RPC 런타임에 고급 캐싱 메커니즘을 허용하므로 RpcEpResolveBinding 함수를 사용하는 것보다 우수합니다.
엔드포인트 선택에 대한 보다 구체적인 제어가 필요한 경우 클라이언트는 RpcMgmtEpEltInqBegin, RpcMgmtEpEltInqNext 및 RpcMgmtEpEltInqDone 함수를 호출하여 한 번에 하나의 엔드포인트 맵 항목을 검색할 수 있습니다.
잘 알려진 엔드포인트를 엔드포인트 맵 데이터베이스로 내보내기
특히 분산 시스템이 잘 알려진 엔드포인트 모델에서 동적 엔드포인트 모델로 전환되는 경우 엔드포인트를 찾는 두 가지 방법을 혼합할 수 있습니다. 이러한 전환에서 서버의 중간 버전은 잘 알려진 엔드포인트를 사용하지만 잘 알려진 엔드포인트를 엔드포인트 맵 데이터베이스에 등록합니다. 이 방법을 사용하면 잘 알려진 엔드포인트를 사용하는 클라이언트와 동적 엔드포인트를 사용하여 연결하는 클라이언트를 사용할 수 있습니다. 모든 서버가 업그레이드되면 동적 엔드포인트만 사용하는 새 클라이언트 버전을 배포할 수 있습니다. 모든 클라이언트가 업그레이드되면 최종 서버 버전은 잘 알려진 엔드포인트 사용을 중지하고 동적 엔드포인트만 사용할 수 있습니다.
이 방법을 사용하면 잘 알려진 엔드포인트로 시작했지만 모든 서버와 클라이언트를 동시에 업데이트하지 않고도 동적 엔드포인트로 마이그레이션하려는 애플리케이션의 전환 경로가 허용됩니다.