운영체제론[6]: 프로세스 간 통신, RPC

Direct Communication (직접 통신)

프로세스는 서로를 명시적으로 이름을 지정한다.

send(P, message) : 메시지를 프로세스 P에게 보낸다.

receive(Q, message) : 메시지를 프로세스 Q에게서 받는다.

 

통신 링크의 특성

- 링크는 자동으로 설정된다.

- 링크는 정확히 하나의 쌍 프로세스와 연관된다.

- 각 쌍 사이에는 정확히 하나의 링크가 있다.

- 링크는 단방향일 수도 있지만, 일반적으로 양방향이다.

 

Indirect Communication (간접 통신)

메시지는 mailbox(또는 port)에서 직접적으로 보내고 받는다.

- 각 mailbox는 고유한 ID를 가진다.

- 프로세스는 mailbox를 공유할 때만 통신할 수 있다.

 

통신 링크의 특성

- 프로세스가 공유하는 mailbox가 없으면 링크를 설정할 수 없다.

- 하나의 링크는 여러 프로세스와 연관될 수 있다.

- 각 쌍의 프로세스는 여러 통신 링크를 공유할 수 있다.

- 링크는 단방향 또는 양방향일 수 있다.

 

동작방법

- 새로운 mailbox(port)를 생성

- mailbox를 통해 메시지를 보내고 받음

- mailbox 삭제

 

Direct Communication과 마찬가지로,

send(P, message) : 메시지를 프로세스 P에게 보낸다.

receive(Q, message) : 메시지를 프로세스 Q에게서 받는다.

의 방식으로 소통한다.

 

P1, P2, P3가 mailbox A를 공유하는 경우, P1이 메시지를 보내고 P2와 P3가 메시지를 받는 경우 메시지를 받는 프로세스는 누구인가?

해결책

=> 링크를 두 프로세스에만 연결하도록 허용

=> 한 번에 하나의 프로세스만 수신 작업을 실행하도록 허용

=> 시스템이 임의의 수신자를 선택하도록 허용. - 송신자에게 수신자가 누구인지 알려줌

 

 

 

Synchronization

메시지 패싱은 블로킹/논블로킹일 수 있다.

 

블로킹은 동기식(syncronization)이다.

blocking send : 메시지를 받을 수 있을 때까지 프로세스가 차단된다. (queue를 사용하면 non-blocking 효과 가능)

blocking receive : 상대가 메시지를 받을 때까지 프로세스가 차단된다.

 

논블로킹은 비동기식(asyncronization)이다.

non-blocking send : 보내는 프로세스가 메시지를 보내고 상대가 받든 말든 계속 실행 - queue를 사용하면 메시지 손실을 막을 수 있음.

non-blocking receive : 들어온 메시지가 없으면 NULL을 받아옴

 

send와 receive가 모두 블로킹인 경우, 랑데뷰(rendezvous)라고 한다. 이 경우 보내는 프로세스와 받는 프로세스가 동시에 메시지를 교환하고, 메시지를 잃어버리거나 불완전하게 교환되는 경우가 없다.

 

 

 

Buffering

버퍼링은 메시지 패싱에서 사용되는 기술로, blocking send/receive의 성능 향상에 사용됨.

링크에 연결된 메시지의 queue가 필요하다.

 

메시지 큐는 다음 세 가지 방법으로 구현할 수 있다.

1. size가 0인 큐 : 메시지를 큐에 저장하지 않고 보내는 프로세스는 받는 프로세스를 기다린다. (랑데뷰)

2. 유한 size의 큐 : 큐가 가득 차면 보내는 프로세스는 대기한다.

3. 무한 size의 큐 : 보내는 프로세스는 메시지를 큐에 저장할 수 있고, 대기하지 않아도 된다.

 

 

 

Example of IPC Systems - POSIX

POSIX는 UNIX 운영체제와 이와 유사한 운영체제에서 사용되는 표준 인터페이스를 정의한 것으로, IPC와 같은 기능을 제공한다.

POSIX는 공유메모리를 사용해서 IPC를 구현할 수 있다.

1. 프로세스의 공유 메모리 세그먼트 생성 - shm_open 함수 호출

2. 생성된 세그먼트의 크기 설정 - ftruncate() 함수 호출

3. 생성된 세그먼트를 메모리에 매핑 - mmap() 함수 호출

4. 공유 메모리에 대한 포인터를 사용해서 읽기/쓰기 작업 수행

 

 

Example of IPC Systems - Windows

윈도우에서는 고급 로컬 프로시저 호출(ALPC)을 통해 IPC 기능을 구현할 수 있다. (RPC와 유사하다)

같은 시스템 상에서 실행 중인 프로세스 간에만 작동한다.

 

ALPC는 port를 사용하여 통신 채널을 설정하고 유지한다.

1. 클라이언트는 서브시스템의 연결 포트 객체에 대한 핸들을 연다.

2. 클라이언트는 연결 요청을 보낸다.

3. 서버는 두 개의 개인 통신 포트를 생성하고 그 중 하나의 핸들을 클라이언트에게 반환한다.

4. 클라이언트와 서버는 해당 포트 핸들을 사용해서 메시지 또는 콜백을 보내고 응답을 수신한다.

-> 응용 프로그램은 서브시스템의 클라이언트로 간주될 수 있다.

 

APLC는 윈도우 API의 일부가 아니라 개발자에게 보이지 않는다. 따라서 Windows API -> RPC -> ALPC를 사용한다.

 

 

 

Pipes

파이프는 두 프로세스 간 통신을 가능하게 하는 도구로서 사용된다. 이때 주요 이슈는 다음과 같다.

- 통신은 단방향 양방향?

- 양방향의 경우 반 이중인가 전 이중인가? (반이중: 수신하는 동안은 송신 불가 / 전이중: 송수신 동시에)

- 파이프는 네트워크를 통해 접근이 가능한가?

 

일반 파이프는 생성한 프로세스 외부에서 접근할 수 없고, 일반적으로 부모 프로세스가 파이프를 생성해서 자식 프로세스와 통신하는데 사용된다.

이름 있는 파이프는 부모-자식 관계 없이 접근 가능하다.

 

 

Ordinary Pipes (= anonymous pipes)

일반 파이프는 생산자-소비자 방식으로 통신 가능하다.

생산자는 파이프의 쓰기 endpoint에 데이터를 쓰고, 소비자는 파이프의 읽기 endpoint에서 데이터를 읽어온다.

따라서 일반 파이프는 단방향 통신만 가능하고, 통신하는 두 프로세스 사이에는 부모자식 관계가 필요하다.

 

 

Named Pipes

이름 있는 파이프는 일반 파이프보다 더 강력하다.

양방향 통신이 가능하고, 통신하는 프로세스 사이에 부모자식 관계가 필요없다.

여러 프로세스가 이름이 지정된 파이프를 사용해서 통신할 수 있다.

이름 있는 파이프는 UNIX / Windows 시스템 모두에게 제공된다.

 

 

 

Socket

소켓이란 통신의 endpoint을 말하고, IP 주소와 포트 번호의 결합이다.

이를 통해 한 호스트 내에서 네트워크 서비스를 구분해낼 수 있다.

1024보다 작은 포트는 표준 서비스에 사용된다.

 

 

 

Remote Procedure Calls (RPC)

RPC는 네트워크 시스템 간 프로시저 호출을 추상화한다. 이는 다시 서비스 구분을 위해 포트를 사용한다.

RPC에서 stubs는 서버에 실제 프로시저에 대한 클라이언트 측 프록시이다.

클라이언트 측 stub은 서버에서 위치를 찾고 매개변수를 marshalls한다.

서버 측 stub은 이 메시지를 받아서 unmarshalling하고 서버에서 프로시저를 실행한다.

 

윈도우에서는 microsoft 인터페이스 정의 언어(MIDL)로 작성된 명세서에서 스텁 코드를 컴파일한다.

 

기계마다 다른 데이터 표현을 처리하기 위해, 외부 데이터 표현(XDL)을 사용한다.

- big-endian과 little-endian을 고려한다.

원격 통신은 로컬 통신보다 실패 가능성이 높다.

- 메시지가 정확히 한 번만 전달되도록 보장한다. (ACK를 사용해서 요청을 받았고 처리되었다는 것을 클라이언트에 알린다. 클라이언트는 메시지를 여러개 보낼 수 있지만 한 번 처리한 메시지는 더 이상 처리하지 않는다.)

운영체제는 일반적으로 클라이언트와 서버를 연결하기 위한 랑데뷰(또는 매치메이커) 서비스를 제공한다.

매치메이커는 포트 바인딩 문제 해결 방법 중 동적인 방식이고, 정적인 방법은 포트 번호를 사전에 할당하기에 바꿀 수 없다.

 

 

아래는 매치메이커를 이용한 RPC 동작 과정이다.