운영 체제의 원격 프로시저 호출(RPC) - TECHCODEVIEW.COM

원격 프로시저 호출(RPC) 건설을 위한 강력한 기술이다 분산형, 클라이언트-서버 기반 애플리케이션 . 이는 기존 로컬 프로시저 호출을 확장하여 호출된 프로시저가 호출 프로시저와 동일한 주소 공간에 존재할 필요는 없습니다. . 두 프로세스는 동일한 시스템에 있을 수도 있고, 네트워크를 통해 연결되는 서로 다른 시스템에 있을 수도 있습니다.

원격 프로시저 호출을 할 때:

1. 호출 환경이 일시 중지되고 프로시저 매개변수가 네트워크를 통해 프로시저가 실행될 환경으로 전송되고 그곳에서 프로시저가 실행됩니다.

6의 10제곱

2. 프로시저가 완료되고 결과가 생성되면 해당 결과는 호출 환경으로 다시 전송되며, 여기서 일반 프로시저 호출에서 반환되는 것처럼 실행이 재개됩니다.

참고: RPC 특히 클라이언트-서버에 매우 적합합니다. (예: 쿼리-응답) 제어 흐름이 이루어지는 상호 작용 발신자와 수신자를 번갈아 가며 . 개념적으로 클라이언트와 서버는 동시에 실행되지 않습니다. 대신 실행 스레드가 호출자에서 호출 수신자로 점프한 다음 다시 돌아옵니다.

RPC 작업

RPC 중에 다음 단계가 수행됩니다.

클라이언트가 클라이언트 스텁 절차 , 일반적인 방법으로 매개변수를 전달합니다. 클라이언트 스텁은 클라이언트 자체 주소 공간 내에 상주합니다.
클라이언트 스텁 마샬(팩) 매개변수를 메시지로 변환합니다. 마샬링에는 매개변수 표현을 표준 형식으로 변환하고 각 매개변수를 메시지에 복사하는 작업이 포함됩니다.
클라이언트 스텁은 메시지를 전송 계층으로 전달하고, 전송 계층은 이를 원격 서버 시스템으로 보냅니다.
서버에서 전송 계층은 메시지를 서버 스텁으로 전달합니다. 디마샬(압축 풀기) 매개변수를 지정하고 일반 프로시저 호출 메커니즘을 사용하여 원하는 서버 루틴을 호출합니다.
서버 프로시저가 완료되면 서버 스텁으로 돌아갑니다. (예: 일반 프로시저 호출 반환을 통해) , 반환 값을 메시지로 마샬링합니다. 그런 다음 서버 스텁은 메시지를 전송 계층으로 전달합니다.
전송 계층은 결과 메시지를 클라이언트 전송 계층으로 다시 보내고, 클라이언트 전송 계층은 메시지를 다시 클라이언트 스텁으로 전달합니다.
클라이언트 스텁은 반환 매개 변수를 정리하고 실행은 호출자에게 반환됩니다.

RPC 시스템 설계 및 구현 시 주요 고려 사항은 다음과 같습니다.

보안: RPC에는 네트워크를 통한 통신이 포함되므로 보안이 주요 관심사입니다. 무단 액세스를 방지하고 민감한 데이터를 보호하려면 인증, 암호화, 권한 부여와 같은 조치를 구현해야 합니다. 확장성: 클라이언트와 서버의 수가 증가함에 따라 RPC 시스템의 성능이 저하되어서는 안 됩니다. 확장성을 위해서는 로드 밸런싱 기술과 효율적인 리소스 활용이 중요합니다. 내결함성: RPC 시스템은 네트워크 오류, 서버 충돌 및 기타 예상치 못한 이벤트에 대해 복원력을 갖춰야 합니다. 중복성, 장애 조치 및 점진적 성능 저하와 같은 조치는 내결함성을 보장하는 데 도움이 될 수 있습니다. 표준화: 여러 가지 RPC 프레임워크와 프로토콜을 사용할 수 있으며, 다양한 플랫폼과 프로그래밍 언어 간의 상호 운용성과 호환성을 보장하기 위해 표준화되고 널리 수용되는 프레임워크를 선택하는 것이 중요합니다. 성능 조정: 최적의 성능을 위해 RPC 시스템을 미세 조정하는 것이 중요합니다. 여기에는 네트워크 프로토콜 최적화, 네트워크를 통해 전송되는 데이터 최소화, RPC 호출과 관련된 대기 시간 및 오버헤드 감소가 포함될 수 있습니다.

RPC 문제 :
해결해야 할 문제:

자바 구분 기호 설정

1. RPC 런타임:
RPC 런타임 시스템은 RPC 메커니즘의 기반이 되는 네트워크 통신을 처리하는 서비스 세트와 루틴 라이브러리입니다. RPC 호출 중에 클라이언트 측 및 서버 측 런타임 시스템의 코드 핸들 바인딩하고, 적절한 프로토콜을 통해 통신을 설정하고, 클라이언트와 서버 간에 호출 데이터를 전달하고, 통신 오류를 처리합니다.

2. 스텁:
스텁의 기능은 다음과 같습니다. 프로그래머가 작성한 애플리케이션 코드에 투명성을 제공합니다. .

재귀 자바

클라이언트 측에서 스텁은 클라이언트의 로컬 프로시저 호출과 런타임 시스템 간의 인터페이스를 처리하고, 데이터를 마샬링 및 언마샬링하고, RPC 런타임 프로토콜을 호출하고, 요청된 경우 일부 바인딩 단계를 수행합니다. 서버 측에서 스텁은 런타임 시스템과 서버에서 실행되는 로컬 관리자 프로시저 간에 유사한 인터페이스를 제공합니다.

3. 바인딩: 클라이언트는 누구에게 전화해야 하는지, 서비스가 어디에 있는지 어떻게 알 수 있나요?
가장 유연한 솔루션은 동적 바인딩을 사용하고 RPC가 처음 만들어질 때 런타임에 서버를 찾는 것입니다. 클라이언트 스텁이 처음 호출되면 이름 서버에 접속하여 서버가 상주하는 전송 주소를 결정합니다.

바인딩은 두 부분으로 구성됩니다.

우리:
찾기:

제공할 서비스가 있는 서버는 해당 서비스에 대한 인터페이스를 내보냅니다. 인터페이스를 내보내면 클라이언트가 사용할 수 있도록 시스템에 등록됩니다. 클라이언트는 통신을 시작하기 전에 (내보낸) 인터페이스를 가져와야 합니다.

4. RPC와 관련된 호출 의미:
주로 다음과 같은 선택으로 분류됩니다.

장점:

RPC는 다음을 제공합니다. 추출 즉, 네트워크 통신의 메시지 전달 특성이 사용자에게 숨겨집니다.
RPC는 성능을 향상시키기 위해 많은 프로토콜 계층을 생략하는 경우가 많습니다. 프로그램이 RPC를 자주 호출할 수 있으므로 약간의 성능 향상도 중요합니다.
RPC를 사용하면 로컬 환경뿐만 아니라 분산 환경에서도 애플리케이션을 사용할 수 있습니다.
RPC 코드를 다시 작성/재개발하는 노력이 최소화됩니다.
RPC가 지원하는 프로세스 지향 및 스레드 지향 모델.

참고자료: