Pipe (파이프)
FIFO (Named Pipe)
Message Queues (메시지 큐)
Shared Memory (b/w processes) (공유 메모리)
write() 시스템 호출로 파이프에 데이터를 씀
read() 시스템 호출로 파이프에서 데이터를 읽음
파이프가 꽉 차거나 비었을 때 자동으로 차단됨 (blocking)
half-duplex (반이중): 한 방향으로만 데이터 흐름 가능
공통 조상을 가진 프로세스끼리만 사용 가능 (보통 부모-자식 관계)
프로세스는 파이프를 직접 전달할 수 없음, 상속받아야만 사용 가능
한 프로세스가 파이프를 생성하면 ➡︎ 모든 자식 프로세스가 이를 상속받음
✔️ 사용하지 않는 파일 디스크립터는 반드시 닫아야 함

FIFO는 이름이 있는 파이프임
관련 없는 프로세스들끼리도 통신 가능
파일 시스템 내의 파일 종류 중 하나
- stat.st_mode == FIFO이면 ➡︎ FIFO임
- S_ISFIFO() 매크로를 사용해 확인할 수 있음
#include <sys/types.h>
#include <sys/stat.h>
int mkfifo(const char *pathname, mode_t mode);
(매개변수)
pathname: FIFO의 파일 이름
mode: 접근 권한 (파일 열기 함수 open()과 동일한 방식)
(반환값)
(FIFO 사용법)

(데이터 흐름도)

$ cat myfifo &
myfifo를 읽는 프로세스를 백그라운드로 실행
아직 출력 안 됨 ➡︎ 데이터를 넣지 않았기 때문
$ cat hello.c | tee myfifo

서버는 "well-known FIFO" (고정된 이름의 FIFO)를 생성해 클라이언트와 통신

클라이언트는 이 FIFO에 write 요청을 보냄
서버는 이 FIFO로부터 요청을 read 함
‼️(문제점)
여러 클라이언트가 같은 FIFO로 요청을 보내면, 서버는 클라이언트에게 개별 응답을 보낼 수 없음
➡︎ 이를 해결하려면 각 클라이언트가 자신만의 응답용 FIFO를 생성해야 함
일정량의 데이터를 메시지 단위로 송수신함
보내는 쪽이 각 메시지를 타입별로 분류함 ➡︎ 특정 타입 메시지만 선택적으로 받을 수 있음
둘 이상의 프로세스가 같은 메모리 영역을 공유할 수 있음
동시에 접근 시에는 semaphore(세마포어)를 이용한 동기화가 필요함
dentifier (식별자): IPC 구조체는 각각 음이 아닌 정수 ID를 가짐
Key: IPC 구조를 만들 때는 key_t 타입의 키가 필요함
ex) id = xxxget(key, …)
(동일 IPC 객체에 접근하는 방법)
공통 헤더 파일에 키 정의
클라이언트와 서버가 해당 키를 사용하기로 합의
서버가 해당 키로 IPC 객체 생성
이미 사용 중인 키일 경우 문제 발생
→ msgget, shmget은 오류 반환
→ 해결: 기존 키 제거 후 새로 생성
msgget, shmget
새 IPC 구조 생성 또는 기존 구조 열기
성공 시 IPC 식별자 반환 / 실패 시 -1과 errno 설정
msgctl, shmctl
상태 확인, 옵션 및 권한 설정
IPC 식별자 제거 가능
msgop, shmop
IPC 객체는 ipc_perm이라는 구조체로 접근 권한과 소유자를 정의함
struct ipc_perm {
uid_t uid; // 소유자의 사용자 ID
gid_t gid; // 소유자의 그룹 ID
uid_t cuid; // 생성자의 사용자 ID
gid_t cgid; // 생성자의 그룹 ID
mode_t mode; // 접근 권한 모드 (r/w 등)
ulong seq; // 슬롯 시퀀스 번호
key_t key; // IPC 키
};
