OS on 오늘도 개발을 한다.

[OS] 동기-비동기, 블로킹-논블로킹 알아보기 (w. I/O 멀티플렉싱)

Fri, 01 Nov 2024 16:43:45 +0900

서론

CS 스터디에서 10월 22일 발표한 동기와 비동기, 블로킹과 논블로킹에 대해 정리한 문서를 블로그에 공유하고자 한다.

동기와 비동기, 블로킹과 논블로킹의 차이에 대하여

두 가지 모두 “연관 되어있는 프로세스/함수간의 작업 순서"에 대해 설명하는 유사한 개념으로 볼 수 있음.
- 하지만 어떠한 것을 중점으로 두는 개념인가는 다름.
  - 동기 - 비동기
    - 작업 순서, 호출 시점 에 중점
      - A 함수가 B 함수를 호출하고, 그 결과를 기다린 뒤 이를 활용해 다음 로직을 수행하는 함수라면, 동기적
  - 블로킹 - 논블로킹
    - 실행 제어권 에 중점
      - A 함수가 B 함수를 호출하고, 제어권을 넘겨준다면 블로킹

동기 - 비동기

출처: Operating System Concepts, 9th Edition

동기

앞의 작업이 완료되어야 이후의 작업이 시작되는 순차적인 처리방식
- 즉, 작업의 순서가 보장됨

비동기

앞의 작업이 완료되길 기다리지 않고 다음 작업을 실행할 수 있는 방식
- 즉, 작업의 순서가 보장되지 않으며, 병렬로 작업이 실행 가능함
  - 이는 각 작업이 독립적이거나, 작업 별 지연시간이 긴 경우 효율적
프로세스 실행 뿐만 아니라, I/O 작업 역시 비동기적으로 처리 가능
- 주로 미리 애플리케이션의 일부 주소 공간에 변수를 설정하거나, 애플리케이션 제어 흐름 외부에서 동작하는 신호(signal), 콜백의 트리거 등을 통해 미래에 I/O 작업이 완료되면 애플리케이션 값을 전달
- 즉, 결과 값을 기다리지 않고 일단 바로 반환함

블로킹 - 논블로킹 (I/O 작업을 예시로)

출처: Blocking vs. Non-Blocking API (kii.com)

블로킹

파일 읽기, 네트워크 요청 등의 I/O 작업을 수행하는 경우, 해당 작업이 완료될 때까지 프로그램 실행 멈춤
- 블로킹 I/O 작업이 호출되면 작업(프로세스)는 실행 대기열(run queue)에서 대기 대기열(wait queue)로 이동하며, I/O 작업이 완료되면 작업은 다시 실행 대기열로 이동함.
  - 이때 실행이 재개되면서 I/O 작업으로 부터 반환된 값을 받음.
- 즉, 프로그램 실행 제어를 I/O 작업에게 넘긴다고 볼 수 있음
대부분의 애플리케이션 인터페이스에서는 블로킹 시스템 콜 사용
- 블로킹 방식이 논블로킹 방식보다 코드 이해가 쉽기 때문

논블로킹

I/O 작업을 수행하는 동안에도 프로그램 실행 멈춤 없이 계속 프로그램 작업 수행
- 주로 이벤트 기반이거나, 콜백 함수를 사용하는 비동기 방식에서 사용됨.
- 이외에도 키보드-마우스 입력을 받아 데이터 처리 및 표시하는 UI, 디스크 파일 읽어서 디스플레이에 출력하는 비디오 프로그램 등이 대표적인 논블로킹 I/O 예시

동기이면서 논블로킹이고, 비동기이면서 블로킹인 경우는 의미가 있다고 할 수 있는가?

두 경우 모두 결과적으로 동기적으로 동작하는, 각각의 특성을 살리지 못하는 방식이라고 볼 수 있음

동기 - 논블로킹

논블로킹 방식이므로 I/O 작업을 수행하는 도중에도 원래 작업(프로세스)을 계속 실행할 수 있음
- 실행 제어권을 넘기지 않기 때문
하지만 동기 방식이므로 I/O 작업 결과가 반환될 때 까지 다음 작업을 수행할 수 없음
- 계속 Polling(프로세스가 실행 가능한 상태를 유지하며 이벤트를 기다리는 것)하며 결과 값을 기다림
결과가 반환될 때까지, 결과가 필요한 이후 작업들을 수행하지 못하므로 사실상 블로킹 형태로 동작
- 다만, 결과가 필요하지 않은 작업들을 수행할 수 있는 경우 유의미

비동기 - 블로킹

비동기 방식이므로 현재 프로세스가 끝나지 않았어도 다른 작업을 수행할 수 있음
하지만 블로킹 방식이므로, I/O 작업을 수행하는 경 현재 프로세스의 실행 제어권을 I/O 작업에게 넘기므로 해당 작업이 끝나기를 기다려야 함
- I/O 작업이 잦은 경우 사실상 동기 형태로 동작

I/O 멀티플렉싱이란?

출처: Week11-Select.pdf

출처 : developer.ibm.com

멀티플렉싱
- 통신에서 여러 시그널 또는 정보 스트림을 하나의 복잡한 신호로 동시에 전송하는 것
I/O 멀티 플렉싱?
- 비동기 블로킹 I/O를 부르는 또 다른 말로, 하나의 프로세스가 여러 파일을 관리할 수 있도록 해주는 기법
  - 프로세스에서 파일에 접근할 때 파일 디스크립터(File Descripter, FD)라는 추상적인 값을 사용
    - 이 파일이라는 것엔 클라이언트와의 연결에 사용되는 소켓 같은 것도 포함됨
      - 소켓 역시 IP/Port를 가진 파일이기 때문
    - 이러한 점에서 다중 클라이언트 연결을 지원하기 위한 대안적인 접근 방식이라고도 불림
- FD를 어떻게 감시하는지, 어떤 상태로 대기하느냐에 따라 select, poll, epoll(linux), kqueue(bsd), iocp(windows)와 같은 기법들이 존재
  - 메인 서버 루프는 select, poll 시스템 콜을 통해 어떤 FD가 준비되었는지 확인
    - 즉, read 또는 write 작업은 block 없이 바로 수행 됨
- 동시성을 위해 프로세스/스레드를 사용하는 것에 비해 다음과 같은 장/단점이 존재
  - 장점: 프로세스/스레드 보다 클라이언트 연결 당 오버헤드(CPU, 메모리)가 적음
  - 단점: 코드 복잡성이 증가함
I/O 멀티 플렉싱의 일반적인 흐름
1. 애플리케이션에서 read 요청
2. 커널은 read I/O처리를 시작함과 동시에, 애플리케이션에게 미완료상태(EAGAIN, 리소스를 일시적으로 사용할 수 없음)임을 반환
3. 애플리케이션은 데이터가 준비되었다는 알람이 올 때 까지 기다림(select())
4. 커널에서 결과 값이 준비되었다는 callback 신호를 보냄
5. 애플리케이션은 데이터를 커널 공간에서 사용자 공간(buffer)으로 복사해옴
  - 실제 구현에서는 select 호출의 유의미한 값이 나올때 까지 애플리케이션은 loop를 돌며 대기

I/O 멀티플렉싱의 여러 구현 방식

select()

#include <sys/select.h>

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

대상 FD를 배열에 집어넣고 하나하나 순차 검색하는 방식
- O(n)의 시간복잡도를 가짐(대상 FD가 늘어날수록 오래 걸림)
이 배열형태의 구조체를 fd_set이라고 부르며, 각 n번째 비트는 n-1 FD에 대응됨
- 해당 비트가 1이면, 대응되는 파일에 변경이 감지되었음을 의미
- 변경을 감지하려면, 매 번 최대 FD 개수만큼 loop를 돌며 비트 값 하나하나를 검사해야 함
고정된 단일 bit table을 사용하므로 관리할 수 있는 최대 FD 수가 1024개로 제한됨

pselect()

int pselect(int nfds, fd_set * readfds, fd_set * writefds, fd_set * exceptfds, const struct timespec * timeout, const sigset_t * sigmask);

select에서 timeout과 signal 처리 로직을 개선한 함수
- timespec 구조체를 사용해 나노초까지 정밀한 컨트롤 가능
- sigmask 인자를 활용해 signal에 의한 인터럽트 발생시 block 시킬 수 있음

poll()

#include <poll.h>
int poll(struct pollfd * fds, nfds_t nfds, int timeout);

하나 이상의 FD에서 이벤트 발생시, Blocking 해제한 뒤 해당 FD로 들어온 데이터에 대한 I/O 작업을 수행하는 방식
- 관리 가능 FD 수에 제한이 있던 select와 달리 무한 개의 FD를 검사할 수 있는 함수
실제 FD 개수(nfds) 만큼만 loop를 돌아, FD 갯수가 적은 경우 select대비 효율적일 수 있음
- 다만 이벤트 전달에 사용되는 메모리가 커(64bit, select는 3bit) FD 수에 따라 성능이 안좋아 질 수 있음

epoll (linux)

#include <sys/epoll.h>


// create
int epoll_create(int size);
// wait
int epoll_wait(int epfd, struct epoll_event * events,
  int maxevents, int timeout);
// control
int epoll_ctl(int epfd, int op, int fd, struct epoll_event * event);

poll()과 유사하지만, FD의 상태를 커널에서 관리해 상태가 바뀐 것을 직접 통지해 주는 방식
- 애플리케이션에서 루프를 돌 필요도 없고, 변화가 감지된 FD의 목록을 반환받으므로, 대상 파일을 추가 탐색할 필요도 없음
Edge Trigger, Level Trigger 두 가지 방식이 존재
- Level Trigger
  - 특정 상태가 유지되는 동안 감지
  - 입력 buffer에 데이터 남아있는 동안 계속 이벤트 등록
- Edge Trigger
  - 특정 상태가 변화하는 시점에만 감지
  - 입력 buffer로 데이터 수신된 그 상황에 한 번만 이벤트 등록

kqueue (bsd)

#include <sys/event.h>

// event를 저장할 새 Queue 커널에 요청
int kqueue(void);

// kqueue에 특정한 이벤트를 등록하고, 보류중인 이벤트를 등록하거나 사용자한테 반환
int kevent(int kq,
  const struct kevent * changelist, int nchanges,
    struct kevent * eventlist, int nevents,
    const struct timespec * timeout);

커널에 이벤트를 저장할 queue를 생성하면, I/O 이벤트가 queue에 쌓이고 사용자가 직접 polling하는 방식
- select, poll 처럼 발생한 FD를 찾는 추가 작업 필요 X

iocp (windows)

윈도우에서 지원하는 I/O 다중화 모델
- 여러 소켓을 하나의 IOCP 객체로 처리
  - 해당 객체 하위에서 동작하는 thread 여러 개가 동시 대기
  - 커널로부터 받는 결과에 따라 thread를 깨우거나 대기
- 완료 루틴(Completion Routine)으로 I/O 작업 완료 통지를 받는 형태로 설계됨
  - 완료 루틴은 콜백 함수와 비슷한 역할로, WSASend/WSARecv 함수를 호출해 I/O 작업이 완료된 시점에 호출됨

논블로킹 I/O에서 결과를 수신하는 방법?

대부분의 논블로킹 프레임워크에서는 논블로킹 I/O의 결과를 수신하기 위해 지속적으로 polling하는 무한 루프, 흔히 이벤트 루프라고 부르는 것을 사용합니다.
애플리케이션에서는 지속적으로 커널에게 read 요청을 보내고, 커널에서는 아직 데이터가 준비되지 않은 경우 EAGAIN/EWOULDBLOCK 오류 코드(‘리소스를 일시적으로 사용할 수 없음’을 의미)를 반환합니다.
만약 데이터가 준비된 경우, 애플리케이션은 커널로부터 데이터를 사용자 공간(buffer)으로 복사해옵니다.
오류 코드를 수신한 시점에 애플리케이션은 read 요청을 또 보낼 지 선택할 수 있어 애플리케이션은 Block되지 않습니다.
이외에도 I/O 작업이 완료된 경우 수행되는 콜백 함수를 설정하거나, I/O 작업이 완료되었다는 signal이 수신되는지 감지하는 방법 등 다양한 방법이 존재합니다.

참고

[OS] IPC 알아보기

Tue, 04 Jun 2024 20:38:16 +0900

서론

CS 스터디에서 6월 4일 발표한 IPC에 대해 정리한 문서를 블로그에 공유하고자 한다.

IPC란?

프로세스 간 통신(IPC, Inter-Process Communication)이란, OS상에서 프로세스간에 정보 공유, 모듈화 등을 이유로 데이터와 정보를 공유하는 행위 또는 방법을 의미합니다.
기본적으로 프로세스들은 서로 독립적이기 때문에 영향을 주지도, 받지도 않습니다. 하지만 정보 공유, 성능 제고, 모듈화 등의 이유로 프로세스간 협력이 필요한 경우, 그들간의 정보 공유를 위한 IPC 메커니즘이 필요하게 됩니다.
IPC는 공유 메모리 모델, 메시지 전송 모델 두 가지의 근본적인 모델과, Client-Server 시스템에서 주로 사용되는 socket, RPC(Remote Procedure Call), pipe 등의 모델이 있습니다.

`공유 메모리 모델(Shared Memory Model)`

공유 메모리 모델(Shared Memory Model)이란, 한 프로세스의 주소공간에 shared memory를 설정하고 다른 프로세스가 해당 공간을 함께 사용하는 방식을 말합니다.
공유 메모리 모델은 하기한 순서대로 진행되며, 한 번 공유 메모리 구역을 설정하고 나면 그 후 통신은 커널이 관여하지 않는다는 특징이 있습니다. (메모리 설정시에는 커널 관여)

한 프로세스가 자신의 주소공간에 Shared Memory 설정(시스템 호출)
다른 프로세스는 공유메모리를 자신의 주소공간에 attach(시스템 호출)
이후 해당 공간을 읽고 씀

`메시지 전송 모델(Message Passing Model)`

메시지 전송 모델(Message Passing Model)이란, 커널 내부의 메시지 큐를 활용해 프로세스간 통신을 수행하는 방식을 말합니다.
고정길이 또는 가변길이 메시지를 송/수신자 간에 주고받는 방식으로, 프로세스간 메모리 공유 없이 동작하므로 분산 환경에 적합합니다.

통신 방법에 따른 명명 방식

메시지 전송 모델의 경우, 메시지를 주고 받을떄 송신자-수신자를 명시하느냐에 따라 직접 통신또는 간접 통신으로 나뉘게 됩니다.

직접 통신

직접 통신 방식이란, send(수신자, msg)와 receive(송신자, &msg)와 같이 송-수신자를 명시하는 일대일 통신 방식을 말합니다. 이때 통신을 원하는 프로세스 간에는 자동적으로 전용 link가 생성되고, 이를 통해 통신이 이뤄지게 됩니다.
추가로 직접 통신 방식 중 receive시 송신자 이름을 기입해야 하는 경우를 대칭 네이밍(Symmetric Naming), 송신자 이름 없이 recieve(&msg)와 같은 형태로 메시지를 수신하는 경우를 비대칭 네이밍(Asymmetric Naming)이라고 합니다.

간접 통신

간접 통신 방식이란, 직접 송-수신자가 통신하지 않고 mailbox 또는 port를 공유하는 다대다 통신 방식을 말합니다. 즉, send(메일박스, msg)와 recieve(메일박스, &msg)를 통해 데이터를 송-수신합니다.
다만 다대다 방식이기 때문에, 둘 이상의 프로세스가 동시에 recieve를 요청할 수 있기 떄문에 어떤 수신자가 이를 수신할 지 선택해야 하는데, 이때 사용되는 방법들은 다음과 같습니다.

연관된 최대 두 프로세스간의 링크를 허용한다.
한 순간에 오직 한 프로세스만 receive() 작업을 실행할 수 있도록 허용한다.
시스템이 메시지를 수신할 프로세스를 임의로 선택하도록 합니다. 즉, 둘 이상의 프로세스 중 하나가 메시지를 수신하게 됩니다.
- 또한, 시스템은 수신자 선택을 위한 알고리즘(ex. 프로세스가 교대로 메시지를 수신하는 라운드-로빈 방식)을 정의할 수 있습니다.

추가로, 메일박스는 프로세스 또는 OS에 의해 소유될 수 있습니다.
만약 프로세스가 소유하는 경우, 자동적으로 메일박스를 소유한 프로세스가 수신자, 해당 메일박스에 메시지를 보내는 프로세스들이 송신자가 되며, 메일박스를 소유한 프로세스가 종료될 경우 메일박스 역시 함께 사라지게 됩니다.
반면에 OS가 메일박스를 소유하는 경우, 이는 어떤 프로세스와도 연결되어 있지 않으며 독립적입니다. 이 경우 OS는 프로세스에게 새 메일박스를 만들고, 메일박스를 통해 메시지를 송-수신하고, 메일박스를 삭제할 수 있는 메커니즘을 제공해야 합니다.

동기화

프로세스 간 통신에서 send, receive 호출의 경우, 여러 설계에 따라 메시지가 동기/비동기적으로 송-수신될 수 있습니다.
송-수신 방법은 각각 다른 방식으로 조합할 수도 있으며, 송-수신 모두 동기식 일 경우, 송-수신 프로세스간에 랑데뷰(Rendezvous) 가 발생할 수 있습니다. 다만, 동기식 송신과 수신을 사용하므로써 생산자-소비자 문제를 약화시킬 수 있습니다.

랑데뷰(Rendezvous) : 특정 소스코드(랑데뷰 포인트)에 도달한 경우, 다른 모든 프로세스들이 도착할 때 까지 해당 지점에서 중지해 있어야 하고, 모든 프로세스들이 도달하면 진행을 이어가는 동기화 방법을 의미합니다. 배리어(Barrier) 라고도 불립니다.

송신

동기적: 송신 프로세스는 메시지가 수신자 또는 메일박스에 도착할 때 까지 block 됩니다.
비동기적: 송신 프로세스는 메시지를 보낸 뒤 기존의 작업을 계속 진행합니다.

수신

동기적: 수신 프로세스는 메시지가 가용할 때 까지 block 됩니다.
비동기적: 수신 프로세스는 유효한 메시지 또는 null 값을 회수합니다.

버퍼링

버퍼링(Buffering)이란, 직접/간접 통신에서 프로세스간 통신에서 교환된 메시지가 저장되는 임시 큐를 말합니다. 기본적으로, 이러한 큐를 구현하는 방식은 3가지가 있습니다.

Zero Capacity: 큐의 길이가 0, 즉 어떠한 메시지도 대기하고 있을 수 없으며 송신 프로세스는 수신자가 메시지를 수신할 때 까지 block 됩니다.
Bounded Capacity: 큐의 길이는 유한(n)해 최대 n개의 메시지가 큐에 상주할 수 있습니다.
- 새 메시지가 전송될 때 큐가 꽉 차있지 않다면 메시지는 큐에 배치되고, 송신 프로세스는 기다리지 않고 작업을 이어나갈 수 있습니다.
- 만약 큐가 꽉 차있다면, 송신 프로세스는 큐에 공간이 생길때 까지 block 됩니다.
Unbounded Capacity: 큐의 길이는 무한하며, 따라서 몇 개의 메시지든 대기할 수 있습니다. 또한, 송신 프로세스는 절대 block되지 않습니다.

`소켓(Socket)`

소켓(Socket)은 통신 종단점을 의미합니다.
네트워크 상에서 통신하는 한 쌍의 프로세스는 각 프로세스마다 하나씩 한 쌍의 소켓을 사용해 통신 링크를 형성합니다. 이때 소켓은 포트 번호와 연결된 IP 주소로 식별됩니다.
포트는 특정 프로세스 또는 네트워크 서비스 타입을 식별하는 논리적 장치로, 특정 서비스별로 잘 알려진 포트들이 사용됩니다.

예시로, telnet은 23번 포트, FTP는 21번 포트, http는 80번 포트를 사용합니다.

서버는 특정 포트를 listen하며 클라이언트의 요청이 들어오기를 기다립니다. 요청이 수신된 경우, 서버는 클라이언트 소켓과의 연결을 수락하여 연결을 완료합니다.
소켓 통신은 C, C++, 특히 Java와 같이 네트워크 관련 라이브러리가 많은 언어에서 구현 가능합니다.
Java에서는 3가지 타입의 socket 구현체를 제공하는데, TCP 소켓 통신에 사용되는 Socket 클래스, UDP 소켓 통신에 사용되는 DatagramSocket, 여러 명의 수신자와 통신할 수 있는 MulticastSocket으로 나눠집니다.
소켓 통신은 흔하고 효율적이긴 하지만, 통신하는 스레드간에 구조화 되지 않은 바이트 스트림만 교환할 수 있기 때문에, 로우-레벨 형태의 분산 프로세스 통신 방법으로 여겨집니다. 따라서, 데이터를 구조화 하는것은 온전히 클라이언트 또는 서버 애플리케이션의 몫입니다.

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

원격 프로시저 호출, 줄여서 RPC는 네트워크로 연결된 시스템 상의 프로세스 간에 추상 프로시저를 호출해 통신하는 방식을 말합니다. 별도의 시스템에 존재하는 프로세스와 통신해야 하기 때문에, 메시지 기반 통신 방식을 사용합니다.
RPC 통신상에서 교환되는 메시지는 구조화되어 있으며, 각 메세지들은 원격 시스템의 포트를 listen하고 있는 RPC 데몬에게 전달됩니다. 이때 각각의 메시지는 실행할 함수의 식별자, 함수에 전달할 파라미터를 포함합니다.

구조

RPC 통신은 클라이언트단의 프록시인 Stub와 서버 단의 프록시인 Skeleton이 통신하는 형태로 이뤄지게 됩니다.

진행 순서

클라이언트가 원격 프로시저를 호출한다. RPC 시스템은 적절한 스터브를 호출해, 원격 프로시저에 제공된 매개변수들을 전달한다.
- 일반적으로 각각의 원격 프로시저 별로 별개의 스터브가 존재한다.
스터브는 서버의 포트를 위치시키고(locate), 매개변수들을 마셜해 네트워크를 통해 전송할 수 있는 형태로 패키징한다.
- 마셜(마셜링): 모으다, 결집시키다라는 뜻을 가지는 단어로, Java에서는 주로 객체를 바이트 스트림나 파일로 변환하는 것을 의미한다. 반대로 바이트 스트림을 객체로 복원하는 언마셜링 이라는 개념도 존재한다.
스터브는 메시지 전송(Message Passing)을 통해 서버에 메시지를 전송한다.
스켈레톤(서버측의 스터브)이 이를 수신하고, 매개변수들을 언마셜한 뒤, 서버의 프로시저를 호출한다.
(필요한 경우) 프로시저 결과 값을 마셜한 뒤, 클라이언트에게 전송한다.
(필요한 경우) 스터브는 수신한 값을 언마셜한 뒤, 클라이언트에게 전달한다.

문제점

클라이언트 - 서버 간 데이터 표현의 차이

시스템 별로 값을 저장할 때 어떤 바이트를 우선하느냐 등의 차이가 존재할 수 있어 아키텍처 별로 데이터를 다른 형태로 저장할 수 있습니다.
이러한 문제를 해결하고자 RPC 시스템들은 데이터의 기계-독립적인 표현을 정의해 사용합니다.
이러한 표현을 외부 데이터 표현(XDR, External Data Representation)이라고 하며, 클라이언트와 서버는 기계-의존적인 표현들을 XDR로 변환하는 마셜링/언마셜링 과정을 거칩니다.

호출의 의미론(Sementic of call)

로컬 프로시저 호출, 즉 시스템 내부에서의 프로시저 호출은 극단적인 상황에서만 발생하는 반면 RPC의 경우 일반적인 네트워크 에러로 인해 프로시처 호출이 실패하거나 중복되어 두 번 이상 실행될 수 있습니다.
이를 해결하기 위해서는 OS가 메시지가 정확히 한 번 동작하도록 보장해야 하는데, 이러한 구현은 난이도가 높습니다.
따라서 RPC에는 오류 조건 처리를 위해 최대 한 번(at-most once), 최소 한 번(at-least once), 정확히 한 번(exactly once) 세 가지의 시멘틱이 사용됩니다.

이미지 출처: At most once, at least once, exactly once - by Alex Xu (bytebytego.com)

최대 한 번(at-most once)의 경우, 메시지가 한 번만 전달되는 방식으로, 메시지가 손실될 수 있지만 재전송되진 않습니다.
이는 각 메시지에 타임스탬프를 붙여 구현할 수 있습니다. 서버는 히스토리를 두고, 이미 히스토리에 존재하는 타임스탬프를 갖는 메시지를 수신할 경우 이를 무시하도록 합니다. 이러한 방식으로 클라이언트는 한 번 이상 메시지를 전송할 수 있고 한 번만 실행됨을 보장받을 수 있습니다.
최소 한 번(at-least once)의 경우, 메시지가 두 번 이상 전달될 수 있는 방식으로, 메시지가 손실되어서는 안됩니다.
정확히 한 번(exactly once)의 경우, 가장 구현하기 힘든 방식으로 메시지가 한 번만, 그것도 손실 없이 전달되어야 하는 방식입니다.
이를 달성하기 위해서는 서버가 요청을 수신할 수 없는 위험을 제거해야 합니다. 따라서 클라이언트에게 RPC 호출이 수신되었고 실행되었음을 알려줄 수 있어야 합니다. 이는 ACK 메시지를 통해 실현될 수 있으며 클라이언트는 RPC 호출에 대한 ACK를 수신할 때 까지 주기적으로 RPC 호출을 재전송해야 합니다.

파이프(Pipe)

파이프(Pipe)란 한 프로세스가 다른 프로세스로 데이터를 전달하는 통신 기법을 말합니다.
설계에 따라 다양한 형태로 구현할 수 있는데, 고려할 점은 다음과 같습니다.

통신 방식
- 단방향(unidirectional): 생산자-소비자 형태로 통신하며, 생산자는 pipe의 write-end에서 쓰기만, 소비자는 pipe의 read-end에서 읽기만 가능합니다.
- 양방향(bidirectional): 서로 송-수신이 가능하며, 반이중(half duplex) 형태의 경우 동시 송-수신이 불가능, 즉 데이터가 한쪽 방향으로만 이동하며 전이중(full duplex) 형태의 경우 동시 송-수신이 가능합니다.
프로세스 관계
- 부모-자식 간 통신
- 임의의 프로세스 간 통신
네트워크
- 로컬에 존재하는 프로세스 간 통신
- 원격 통신 가능

또한, 파이프는 Ordinary Pipe와 Named Pipe 두 종류로 나뉩니다.

`일반 파이프(Ordinary Pipe)`

오직 단방향이며, 부모-자식간의 통신만 가능한 파이프를 말합니다.
부모가 생성하고 자식이 상속하는 형태로 연결되며, 파일처럼 취급(Unix의 경우 file read/write 시스템호출을 사용해 통신)합니다.

`명명된 파이프(Named Pipe)`

양방향 통신이 가능하며, 임의의 프로세스들 간 통신을 지원하는 파이프를 말합니다.
시스템이 가동되는 동안 지속될 수 있으며, 일반 파이프와 마찬가지로 파일처럼 취급됩니다.
운영체제 종류(Unix 또는 Windows)에 따라 동작 방식이 다릅니다.

Unix의 경우

Byte 단위로 데이터를 전송하며, 반이중 통신 형태로만 통신할 수 있고, 로컬 내 프로세스 간에서의 통신만 가능합니다.

Windws의 경우

Byte 및 메시지 단위로 데이터를 전송하며, 전이중 통신 형태로 통신할 수 있으며, 원격 간 통신도 가능합니다.

참조

Operating System Concepts - 9th Edition
전공과목(운영체제) 강의 자료
Message Passing (lmu.edu)
2021-OS_06-IPC.pdf (korea.ac.kr)
At most once, at least once, exactly once - by Alex Xu (bytebytego.com)