RFC-5531

출처:https://nebulab.it/blog/driving-organizational-change-with-rfcs/

RFC-5531

RPC 프로토콜은 caller 프로세스와 서버의 프로세스는 서로 로직적으로 통하게 된다.

caller 프로세서는 첫째로 서버 프로세스에게 요청 메세지를 전달한다.

그 요청 메세지에는 프로시저의 파라미터를 포함하고 있으며, 응답 메세지에는 해당 프로시저의 응답을 포함하고 있다.

프로시저로부터 응답값을 받게되고 이후에 caller 프로세스는 이후 실행을 계속 실행한다.

 

서버측면에서 봤을 때, 프로세스는 요청 메세지가 오기전까지 기다리게 된다.

요청 메세지가 도착하게 되면, 서버 프로세스는 프로시저의 파라미터를 가져와 결과를 계산한다.

그리고 응답 메세지를 보내고, 다음 요청을 대기하게 된다.

 

RPC 콜은 LPC(Local Procedure Call) 와는 다른 몇가지 중요한 점이 있다.

1. 에러핸들링 : RPC 통신을 사용할 때, 리모트 서버 또는 네티워크의 실패는 반드시 핸들링 되어야한다.
2. 전역 변수와 부작용
3. 성능 : RPC 호출은 일반적으로 하나 이상의 LPC 보다 느리다.
4. 인증 : RPC 호출은 보안되지 않은 네트워크를 통해 전송되는 경우 인증이 필요할 수 있다. 여기서의 인증은 한 엔티티가  다른 엔티티로 가장하는 것을 방지한다.

 

인증

RPC 는 클라이언트 각 호출 및 응답 메세지에서 서비스에 대해 자신 스스로를 식별 하는데 필요한 필드를 제공하고 그 반대의 경우에도 마찬가지고 제공한다.

또한, 몇몇의 다른 인증 프로토콜도 지원한다.

RPC 헤더에서 어떤 프로토콜을 사용하는지 식별할 수 있다.

RPC 프로토콜 요구조건

1. 호출할 프로시저의 고유한 명세
2. 요청 메세지에 응답 메세지가 일치하는 규정
3. 서비스에 대한 호출자를 인증하기 위한 규정 또는 그 반대의 경우도 포함된다.

 

이외에도 프로토콜 롤오버 오류, 구현 버그, 사용자 오류 및 네트워크 관리로 인한 오류 때문에 아래와 같은 사항을 감지하는 기능이 필요하다.

1. RPC 프로토콜 불일치
2. 원격 프로그램 프로토콜 버전 불일치
3. 프로토콜 오류(ex 프로시저 매개변수의 불일치)
4. 원하는 절차가 호출되지 않은 기타 이유

 

RPC 프로그램 및 절차

RPC 호출할 메세지에는 호출할 프로시저를 고유하게 식별하는 3개의 정수 필드가 존재한다.

1. 원격 프로그램 번호
2. 원격 프로그램 버전 번호
3. 원격 프로시저 번호

원격 프로그램 번호

구현자는 프로그램 번호를 가지고, 원격 프로그램으로 구현할 수 있다.

0이 아닌 숫자이어야 하고 대부분 1을 사용한다.

 

원격 프로그램 버전 번호

호출자가 사용중인 프로토콜의 버전이다.

버전 번호는 같은 서버 프로세스를 통한 이전 프로토콜과 새 프로토콜을 모두 지원할 수 있다.

 

원격 프로시저 번호

호출할 프로시저를 식별한다.

이 숫자들은 특정 프로그램 프로토콜 스펙에 명시되어있다.

예를 들어서, 파일 서비스의 프로토콜 스펙에서 읽음은 5, 쓰기는 12를 사용한다.

 

원격 프로그램 프로토콜이 여러 버전에서 변경 될 수 있는 것 처럼 실제 RPC 메세지 프로토콜도 변경될 수 있다.

따라서, 요청 메세지 또한 안에 RPC 버전 번호가 항상 존재한다.

 

요청 메세지에 대한 응답 메세지에는 충분한 정보가 있다. 그러나 아래와 같은 오류 조건을 구별해야한다.

1. RPC의 구현은 버전번호 2를 지원하지 않는다.
2. 원격 프로그램은 원격 시스템에서는 불가능하다.
3. 원격 프로그램은 요청 버전 번호를 지원하지 않는다.
4. 요청 프로시저 번호는 존재하지 않는다(일반적으로 클아이언트측 프로토콜 또는 프로그래밍 오류)
5. 원격 프로시저에서의 파라미터는 서버의 관점에서는 불필요한 데이터롤 보여진다.

 

RPC Message Protocols

메세지 타입

adaptor - procedure

enum msg_type {

   CALL  = 0,

   REPLY = 1

};

 

Reply 는 아래와 같은 두가지 형태를 취할 수 있다.

enum reply_stat {

    MSG_ACCEPTED = 0,

    MSG_DENIED   = 1

};

그리고, 응답이 ACCEPTED 인 경우와 REJECT 인 경우 아래와 같은 형태를 가지게 된다.

// ACCEPTED 인 경우

enum accept_stat {

    SUCCESS       = 0, /* RPC executed successfully       */

    PROG_UNAVAIL  = 1, /* remote hasn't exported program  */

    PROG_MISMATCH = 2, /* remote can't support version #  */

    PROC_UNAVAIL  = 3, /* program can't support procedure */

    GARBAGE_ARGS  = 4, /* procedure can't decode params   */

    SYSTEM_ERR    = 5  /* e.g. memory allocation failure  */

};

REJECT 인 경우

// REJECT 인 경우

enum reject_stat {

    RPC_MISMATCH = 0, /* RPC version number != 2          */

    AUTH_ERROR = 1    /* remote can't authenticate caller */

};

인증에 실패한 경우

enum auth_stat {

    AUTH_OK           = 0,  /* success                        */

    /*

    * failed at remote end

    */

    AUTH_BADCRED      = 1,  /* bad credential (seal broken)   */

    AUTH_REJECTEDCRED = 2,  /* client must begin new session  */

    AUTH_BADVERF      = 3,  /* bad verifier (seal broken)     */

    AUTH_REJECTEDVERF = 4,  /* verifier expired or replayed   */

    AUTH_TOOWEAK      = 5,  /* rejected for security reasons  */

    /*

    * failed locally

    */

    AUTH_INVALIDRESP  = 6,  /* bogus response verifier        */

    AUTH_FAILED       = 7,  /* reason unknown                 */

    /*

    * AUTH_KERB errors; deprecated.  See [RFC2695]

    */

    AUTH_KERB_GENERIC = 8,  /* kerberos generic error */

    AUTH_TIMEEXPIRE = 9,    /* time of credential expired */

    AUTH_TKT_FILE = 10,     /* problem with ticket file */

    AUTH_DECODE = 11,       /* can't decode authenticator */

    AUTH_NET_ADDR = 12,     /* wrong net address in ticket */

    /*

    * RPCSEC_GSS GSS related errors

    */

    RPCSEC_GSS_CREDPROBLEM = 13, /* no credentials for user */

    RPCSEC_GSS_CTXPROBLEM = 14   /* problem with context */

};