본문 바로가기
CS/OS

IPC

by yongckim 2022. 9. 4.
728x90
반응형

독립적인 프로세스와 협력적인 프로세스

운영체제 내에서 실행되는 프로세스들은 독립적이거나 또는 서로 협력하는 프로세스들일 수 있습니다.

  • 독립적인 프로세스 : 프로세스가 시스템에서 실행 중인 다른 프로세스들과 데이터를 공유하지 않는 프로세스
  • 협력적인 프로세스 : 프로세스가 시스템에서 실행 중인 다른 프로세스들에 영향을 주거나 받는 프로세스

프로세스간 협력을 허용하는 이유

  • 정보 공유 : 여러 응용 프로그램이 동일한 정보에 접근해야할 필요가 있으므로(예를들어, 복사와 붙여넣기) 그러한 정보를 접근할 수 있는 환경을 제공해야 합니다.
  • 계산 가속화 : 특정 작업을 빨리 실행하고 싶으면 작업을 나누어서 각각 병렬로 실행될 수 있게 해야합니다. 단, 이러한 가속화는 여러개의 CPU 코어를 가진 경우에만 가능합니다.
  • 모듈성 : 시스템 기능을 별도의 프로세스 혹은 쓰레드로 나누어 모듈식 형태로 시스템을 구성하기 위해서 사용됩니다.

프로세스가 통신하는 방법

협력적인 프로세스들은 데이터를 교환하기 위해서는 프로세스 간 통신(IPC) 기법이 필요합니다.

IPC에는 기본적으로 공유 메모리(shared memory)와 메시지 전달(message passing)의 두가지 모델이 있습니다.

공유 메모리 모델

공유 메모리를 사용하는 프로세스 간 통신에서는 통신하는 프로세스들이 공유 메모리 영역을 구축해야 합니다.

일반적으로 공유 메모리 영역은 공유 메모리 세그먼트를 생성하는 프로세스의 주소 공간에 위치합니다.

이 공유 메모리 세그먼트를 이용하여 통신하고자 하는 다른 프로세스들은 이 세그먼트를 자신의 주소 공간에 추가하여야 합니다.

일반적으로, 운영체제는 한 프로세스가 다른 프로세스의 메모리에 접근하는 것을 금지하기 때문에 공유 메모리는 둘 이상의 프로세스가 제약 조건을 제거하는 것에 동의해야 합니다.

메시지 전달 모델

커널을 경유하여 메시지를 송수신자 끼리 주고 받으며, 커널에서는 데이터를 버퍼링합니다.

공유 메모리 방식에서는 동일한 주소 공간을 공유했었지만 메시지 전달 방식은 동일한 주소 공간을 공유하지 않고도 프로세스들이 통신하고 동작을 동기화할 수 있도록 허용하는 기법을 제공합니다.

메시지 전달 방식은 통신하는 프로세스들이 네트워크에 의해 연결된 다른 컴퓨터들에 존재할 수 있는 분산환경에서 특히 유용합니다.

메시지 전달 시스템은 최소한 두 가지 연산을 제공합니니다.

  • send(message)
  • receive(message)

프로세스가 보낸 메시지는 고정 길이일 수도, 가변 길이일 수도 있습니다.

메시지 전달 모델은 다양한 방식이 있는데 메시지큐, 파이프, 소켓, 원격 프로시저 호출(RPC)등이 있습니다.

공유 메모리 모델 VS 메시지 전달 모델

  • 공유 메시지 모델 ✌️
    • 메시지 전달 모델의 경우 시스템 콜을 사용하여 데이터에 접근하므로 커널 간섭 등의 부가적인 시간이 소요되기 때문에 바로 데이터에 접근 가능한 공유 메모리 모델이 더 빠릅니다. (공유 메모리 모델 같은 경우 처음 메모리 영역을 생성할 때만 시스템 콜을 사용하게 됨)
  • 메시지 전달 모델 ✌️
    • 메시지 전달 모델은 충돌을 회피할 필요가 없기 때문에 적은 양의 데이터를 교환하는데 유용합니다.
    • 분산 시스템에서 공유 메모리보다 구현이 쉽습니다. (분산 시스템이 따로 분산 공유 메모리를 제공하지 않는 환경일 경우에만)

파이프

파이프는 두 프로세스가 통신할 수 있게 하는 통로입니다.

파이프는 구현방식에 따라 나뉘게 되는데 다음 4가지 문제를 고려하여 구현해야 합니다.

  1. 파이프가 단방향 통신 또는 양방향 통신을 허용하는지
  2. 양방향 통신이 허용된다면 반이중 방식(한 번에 한 방향으로만 전송 가능)인지, 전이중 방식(동시에 양방향 데이터 전송 가능)인지
  3. 통신하는 프로세스간의 부모 - 자식 같은 특정 관계가 존재해야 하는지
  4. 네트워크를 통하여 통신이 가능해야 하는지 아니면 로컬에서만 통신이 이루어지는지

일반 파이프(ordinary pipe)

일반 파이프의 경우 한 방향에서는 쓰기만하고, 다른 방향에서는 읽기만 하게 됩니다.

즉, 단방향 통신으로 이루어집니다.

프로세스가 종료되면 일반 파이프도 자동으로 소멸됩니다.

만일 일반 파이프로 양방향 통신을 구현하고 싶다면 두개의 일반 파이프를 사용해야 합니다.

일반 파이프는 윈도우에서 익명 파이프라고 불립니다. (익명 파이프는 반드시 두 프로세스가 부모 - 자식 관계를 형성하고 있어야 합니다.)

지명 파이프 (named pipe)

지명 파이프는 일반 파이프를 확장한 것으로, 양방향 통신을 지원하며, 부모 - 자식 관계같은 관계도 필요하지 않습니다.

일반 파이프와는 달리 여러 프로세스가 쓸 수 있으며 프로세스가 소멸해도 계속 존재하기 때문에 사용하지 않을 경우 제거할 필요가 있습니다.

클라이언트 - 서버 환경에서의 프로세스간 통신

프로세스는 로컬 뿐만 아니라, 네트워크에 있는 서로 다른 장비에 있는 프로세스끼리도 통신이 가능합니다.

대표적으로 소켓과, 원격 프로시저 호출(RPC)가 있습니다.

소켓(Socket)

소켓은 통신의 양 끝점을 의미하며, 두 프로세스가 네트워크 상에서 통신을 하려면 양 프로세스가 하나씩 총 두개의 소켓을 필요합니다.

각 소켓은 IP주소와 포트 번호 두가지를 결합해서 구별합니다.

일반적으로 소켓은 클라이언트 - 서버 구조를 사용하며 다음과 같이 통신을 하게 됩니다.

  1. 서버는 지정된 포트에 클라이언트가 연결 요청 메시지를 수신 대기합니다.
  2. 클라이언트에서 연결 요청 메시지를 보내면 요청을 수락합니다.
  3. 클라이언트와 서버가 연결됩니다.

소켓을 이용한 통신은 분산된 프로세스 간에 널리 사용되고 효율적이지만 스레드간의 구조화되지 않은 바이트 스트림만을 통신하기에 이를 해석하는 것과 클라이언트 - 서버가 연결하는 부분을 직접 구현해야하기 때문에 구현에 어려움이 있습니다.

원격 프로시저 호출(RPC, Remote Procedure Call)

RPC는 네트워크로 연결된 서버의 프로시저(함수, 메서드등을 의미)를 원격으로 호출하는 기능입니다.

RPC를 사용하면 클라이언트 - 서버 간의 통신을 위한 연결 부분은 직접 구현하지 않아도 되며 원격의 서버에 프로시저 호출을 할 수 있습니다.

RPC는 IDL(Interface Definition Language)를 사용하여 클라이언트와 서버간의 호출 규약을 정의하며 Stub을 통해 프로시저 호출에 사용되는 매개변수를 변환합니다.

Stub을 통해 매개변수 변환을 하기 때문에 원격 서버의 프로시저를 호출할 때 원격 서버에서 로컬 함수를 호출하는 것 처럼 사용할 수 있습니다.

클라이언트 Stub은 함수 호출에 사용된 매개변수의 매개변수의 변환(Mashalling)과 함수 실행 후 서버에서 전달된 결과의 역변환(Unmashalling)을 담당합니다.

클라이언트 Stub에 대응되는 서버 측의 Stub인 Skeleton은 클라이언트가 전달한 매개변수의 역변환과 함수 실행 후 변환을 담당합니다.

다음 그림은 RPC가 통신을 하게 되는 과정입니다.

  • 클라이언트 → 서버
    1. 클라이언트는 매개변수를 클라이언트 Stub에 전달합니다.
    2. 클라이언트 Stub에서 매개변수를 변환(Mashlling)합니다.
    3. RPC 클라이언트 런타임 라이브러리 함수를 호출하여 서버에 변환한 매개변수와 함게 요청합니다.
    4. 서버 RPC 런타임 라이브러리 함수는 요청을 수락하고 서버 Stub 프로시저(Skeleton)를 호출합니다.
    5. 서버 Stub은 네트워크 버퍼에서 매개변수를 검색하여 네트워크 전송 형식에서 서버에 필요한 형식으로 변환합니다.
    6. 서버 Stub은 서버에서 실제 프로시저를 호출합니다.
  • 서버 → 클라이언트
    1. 원격 프로시저는 해당 데이터를 서버 Stub에 반환합니다.
    2. 서버 Stub은 네트워크를 통해 전송하는데 필요한 형식으로 출력 매개 변수를 변환하고 RPC 런타임 라이브러리 함수로 반환합니다.
    3. 서버 RPC 런타임 라이브러리 함수는 네트워크의 데이터를 클라이언트 컴퓨터로 전송합니다.
    4. 클라이언트 RPC 런타임 라이브러리는 원격 프로시저 반환 값을 받아 클라이언트 스텁에 반환합니다.
    5. 클라이언트 Stub을 해당 데이터의 클라이언트 컴퓨터에서 사용하는 형식으로 역변환합니다.
    6. 클라이언트 Stub은 클라이언트 메모리에 데이터를 기록하고 결과를 클라이언트의 호출 프로그램에 반환합니다.

RPC는 다음에 장점을 가지고 있습니다.

  • 원격의 서버를 로컬 환경처럼 사용할 수 있습니다.
  • IDL 기반의 뛰어난 확장성을 가지고 있습니다.
  • 분산 프로그래밍 환경을 구현하는데 유용합니다.

RPC는 장점이 많지만 구현 난이도가 높다는 문제가 있습니다.

정리

  • 프로세스는 다른 프로세스와 영향을 주는지 여부에 따라 독립적인 프로세스, 협력적인 프로세스로 나뉩니다.
  • 협력적인 프로세스들이 데이터를 교환하기 위해서 프로세스 간 통신(IPC) 기법을 사용합니다.
  • IPC에는 공유 메모리와 메시지 전달 모델이 존재합니다.
  • 공유 메모리 모델은 프로세스간 공유되는 메모리 영역을 생성하고 공유된 메모리에 데이터를 읽고 쓰는 방식입니다.
  • 메시지 전달 모델은 커널을 경유하여 메시지를 송수신자끼리 주고 받으며, 커널에서는 데이터를 버퍼링합니다.
  • 파이프는 두 프로세스가 통신할 수 있게 하는 통로로, 일반 파이프와 지명 파이프가 존재합니다.
  • 클라이언트와 서버 환경에 프로세스간 통신은 소켓과 원격 프로시저 호출(RPC)가 존재합니다.
  • 소켓은 IP와 포트번호를 사용하여 통신합니다.
  • 원격 프로시저 호출은 네트워크로 연결된 서버의 프로시저(함수, 메서드 등을 의미)를 원격으로 호출하는 기능입니다.
반응형

'CS > OS' 카테고리의 다른 글

경쟁상황 (Race Condition), 뮤텍스, 세마포어  (0) 2022.09.11
CPU 스케줄링  (0) 2022.09.07
프로세스와 스레드  (0) 2022.08.31
시스템 콜  (0) 2022.08.30
운영체제와 IO / Interrupt  (0) 2022.08.28