[운영체제 공룡책] 3. Process - 프로세스 간 통신 (IPC, Inter-Process Communication)

프로세스 간 통신 (IPC, Inter-Process Communication)

3.4 Interprocess Communication

• Process는 두 가지 타입으로 concurrently하게 수행된다
  • independent (독립적)
    • 공유하는 데이터가 없음
  • cooperating (협력적)
    • 다른 프로세스에 의해 영향을 주거나 받음
    • cooperating 프로세스들 간 공유하는 데이터(shares data)가 있음
• IPC(Inter-Process Communication) : 공유하는 데이터가 있는 경우 발생할 수 있는 커뮤니케이션 이슈를 해결하기 위함
• IPC의 두 가지 모델
  • shared memory
  • message passing

3.5 IPC in Shared-Memory Systems

• 생산자-소비자 문제 (Producer-Consumer Problem) : IPC 에서 발생할 수 있는 가장 기본적인 문제
  • producer : 정보 생산자
  • consumer : 정보 소비자
  • ex) 컴파일러는 어셈블리 코드를 생산하고, 어샘블러는 소비함. 웹서버는 html 파일을 생산하고, 브라우저는 소비함
• 생산자-소비자 문제를 shared-memory를 이용하여 해결해보자 (프로그래머, in/out)
  • 생산자, 소비자 프로세스가 concurrently 하게 실행이 됨. 중간에 buffer 을 둬서 서로 데이터를 주고 받음. 생산자는 버퍼를 채우고 소비자는 버퍼에 있는 값을 소비하여 비우는 것임
  • buffer가 가득 차버리면 생산자는 waitng, buffer가 비어있으면 소비자는 waiting. 이 버퍼를 공유 메모리로 사용하면 되겠지? 생산자와 소비자가 공유하는 메모리 공간!
  • 구현방법은 다음시간에 이어서 ㄱㄱ
  • 이 공유 메모리의 단점은 뭘까? 메모리 쓰고 읽는 걸 application 프로그래머에게 맡김

3.6 IPC in Message-Passing Systems

• 생산자-소비자 문제를 Message-Passing 을 이용하여 해결해보자 (OS, send/receive)
  • OS에서는 cooperating processes들 간 통신을 하기 위한 시스템콜을 제공해줌
  • Communication Links
    • P 와 Q 프로세스가 서로 통신을 원할 때 send 와 receive 메시지를 보내고 받고의 기능만 있으면 된당
    • 커뮤니케이션 링크의 여러 가지 구현 방법 : direct or indiret, synchronous or asynchronous, aotomatic or explicit buffering
  • [참고] prosumer N:M 으로 통신을 해야한다면 단순한 메시지 패싱 방식으로는 어려우니 shared memory 구현을 통해 이런 구성도를 관리할 수 있도록 해볼 예정
• 메시지 페싱의 direct 통신
  • 명시적으로 recipient 프로세스와 sender 프로세스가 서로 통신할때, Link는 automatically 생성되고 두 프로세스 사이에 하나의 링크가 연결된다.
  • send(P, message) - send a message to process P
  • receive(Q, message) - receive a message from process Q
• 메시지 페싱의 indirect 통신
  • 중간 매게체인 mailbox(혹은 port)를 통해서 메시지를 주고 받음
  • 어떤 객체의 추상화된 모습이며, 프로세스에 의해 메시지를 넣을 수도 있고, 메시지를 제거할 수도 있음
  • send(A, message) - send a message to mailbox A
  • receive(A, meessage) - receive a messgae from mailbox A
  • 프로세스들의 페어 사이에 링크가 생성됨 a shared mailbox
  • 2개 이상의 프로세스들의 연결될 수 있음
  • 하나의 메일 박스에는 여러 링크들이 존재할 수 있음
• OS가 mailbox 메카니즘을 위해 프로세스에게 제공하는 것
  • create a new mailbox
  • send and receive message throuht the mailbox
  • delete a bailbox
  • mailbox의 indirect 통신 예시 : OS에 80 port(mailbox)는 웹브라우저의 리스너 포트로 사용
• 실제 구현 시에는 더 다양한 디자인 옵션 존재
  • blocking or non-blocking : synchronous or asynchronous : 보통 blocking은 sycnronous, non-blocking은 asynchronous라고 생각하지만 동일한 개념이 아님
    • non-blocking와 async
    • blocking과 sync
    • 최악은 async 인데 blocking 한 거 (개발자의 실수)
  • Blocking send : 수신자가 메시지를 받을때까지 송신자는 블록됨. 만약 P와 Q 사이의 버퍼가 2G인데 Q가 소비를 빠르게 하지 않아서 P는 버퍼가 비워지기를 기다림
  • Non-blocking send : 송신자는 메시지를 지속적으로 보낼 수 있음. OS가 P가 보내는 데이터를 임시로 보관해두다가 버퍼가 비면 데이터를 보내줌
  • Blocking receive : 수신자는 모든 데이터가 도착할 때 까지 블록됨
  • Non-blocking receive : the receiver retrieves either a valid message or a null message

---

프로세스간 통신의 실제

3.7 Examples of IPC Systems

• IPC 시스템의 예제
  • Shared Memory : POSIX shared memory
  • Message passing : pipes
• POSIX shared memory
  • memory-mapped files를 이용! file을 shared memory로 사용
  • 근데 일일히 파일 생성하고 메모리 할당하고 그러는거 귀찮잖아~ pipes 에 대해 알아보자~
• Pipes
  • 유닉스에서 초창기에 사용하던 매커니즘
  • pipe는 두 개의 프로세스가 통신하는 도구처럼 행동함
• pipe 구현의 4가지 이슈
  • unidirectional or bidirectional? 양방향은 골치아프니까 unidirectional(한쪽방향)하게 함
  • two-way communication, half-duplex or full duplex? 왔다갔다 할 수 있는가? P, Q 파이프 두개 만들면 되니까 가능
  • relationship? 그럴 필요는 없지만 구현 편의상 parent-child 관계를 갖도록 한다
  • over network? 노노. 네트워크에서 동작할 수 없음. 네트워크에서 쓸 수 있는 파이프는 socket이라 부름
• 두 가지 유형의 pipes
  • Ordinary pipes (우리는 이것만 볼거임)
    • cannot be accessed from outside the process that created it.
    • Typically, a parent process creates a pipe and uses it to communicate with a child process that it created.
  • Named pipes : 부모-자식 관계까 아니어도 사용할 수 있음. 파이프에 이름을 부여함
• Ordinary pipe
  • 아래처럼 파이프 두 개 둬서 양방향 통신 가능~
  • one-way인 unidirectional 파이프를 두 개 하면 되는거늬까~

3.8 Communication in Client-Server Systems

• client-server 시스템의 두 가지 전략
  • Sockets : IP주소와 Port를 이용하여 Link 한 것을 Socket
    • IP 주소로 endpoint를 특정함
    • Port로 pipe를 특정함
    • 단점 : 주소체계(64bit, 32bit)와 배열 방법(리틀엔디안, 빅엔디안)이 달라서 서로 통신하려면 이런 저런 약속을 많이 해야했음 → 그래서 나온게 RPC!
  • RPCs (Remote Procedure Calls) - (gRPC 떠오른다)
    • 원격에 있는 프로세스들 간의 호출을 추상화함
    • 원격에 있는 함수를 호출하는 걸 RPC라고 함~
• Socket
  • IP와 port를 하나로 묶으면 컴퓨터를 특정할 수 있음!
• Java
  • 자바에서 소켓 프로그래밍에 쉬운 인터페이스를 잘 제공해줌
  • 3개의 소켓 클래스를 제공함
    • Socket class : connection-oriented (TCP)
    • DatagramSocket class : connectionless (UDP)
    • MulicastSocket class : mulriple recipients
• RPC (예제 만들기 복잡해서 말로만 설명)
  • Java - RMI로 구현되어 있음
  • client가 remote에 있는 함수를 실행할 수 있게 해줘야함
  • client side에 있는 stub을 통해서 Server side에 있는 skeleton을 호출해야하는 거임
  • 근데 이렇게되면 리틀엔디안/빅엔디안 이슈나 직렬/역직렬 이슈도 있겠지
  • 서버끼리 주고받을 데이터(parameters)를 정렬하는 것을 marshals 이라고 함

---

느낀점

근본을 배우고 있다는 느낌이 든다. pub/sub도 IPC에서 착안된 개념이고, 더 쉽게 사용할 수 있게 추상화하여 구현해서 AWS에서 제공하고 있는 느낌적인 느낌.