Inter-Process Communication (IPC)
Contents
• Inter-Process Communication (IPC)
– Message passing
– Shared memory
– Signals
– Pipes
• Communication in Client-Server Systems
– Sockets
– Remote Procedure Calls (RPCs)
Inter-Process Communication (IPC)
• Processes within a system may be independent or cooperating
– Independent process cannot affect or be affected by the execution of another process
– Cooperating process (두 개 이상의 process가 상호작용(IPC 매커니즘)하면서 동작) can affect or be affected by other processes, including sharing data
• Reasons for cooperating processes:
– Information sharing
– Computation speedup
– Modularity
– Convenience
• Cooperating processes require an IPC mechanism that will allow them to exchange data
• Two fundamental models of IPC:
– Message passing & Shared memory
Two Fundamental IPC Models (1/2)
1) Message-passing model: Communication takes place by means of messages exchanged between the cooperating
processes 5
– Useful in a distributed environment
Microkernel!!
– Typically implemented using system calls, thus requiring the more time-consuming task of kernel intervention
– Two key operations: send(message) & receive(message)
메세지 패싱 모델은 협력 프로세스 간에 교환되는 메세지를 통해 통신이 발생한다.
왼쪽과 같이 메세지 큐를 사용해 프로세스 간 메세지를 주고 받는 다.
이러한 방법은 마이크로 커널같은 분산 환경에 유용하다.
Message Passing
• Producer-consumer becomes trivial
– Processes need to:
1) Establish a communication link between them
2) Exchange messages via send/receive methods
이러한 메세지 패싱 모델의 특징은 일반적으로 시스템 콜을 사용하여 구현된다. 즉 주요 사업(send, receive) 등을 할 때 커널이 개입되어야 하는데, 이것 때문에 많은 시간이 소요된다는 단점이 있다.
Two Fundamental IPC Models (2/2)
• Shared-memory model:
Cooperating processes establish a region of shared memory and then they can exchange information by reading and writing data in the shared areas
– Typically, a shared memory region resides in the address space of the process creating the shared-memory segment
– Faster than message passing because system calls are required only to establish shared memory regions.
Once established, all accesses are treated as routine memory accesses, and no assistance from kernel is required
Two Fundamental IPC Models (2/2)
– The communication here is under the control of the users’ processes, not under the OS’s control (message passing보다 더 빠른 이유)
– Major issue is how to provide mechanism that will allow the user processes to synchronize their actions when they access shared memory (두 프로세스가 동시에 shared memory에 접근할 때는 synchronize에 관련한 매커니즘 필요,)
Shared Memory
• POSIX Shared Memory (POSIX API를 이용해 shared memory 사용 가능)
– Process first creates shared memory segment
shm_fd = shm_open(name, O_CREAT | O_RDWR, 0666);
Also used to open an existing segment to share it
– Set the size of the segment
ftruncate(shm_fd, 4096);
– Map the shared memory segment to a specific memory region
(중요/ File I/O operation 사용하지 않고 더 빨리 read/write 가능)
ptr = mmap(0, size, PROT_WRITE, MAP_SHARED, shm_fd, 0);
– Now the process could write to the shared memory
sprintf(ptr, "Writing to shared memory");
Shared Memory
• IPC POSIX Producer
Shared Memory
• IPC POSIX Consumer
What about IPC in Linux?
• Linux provides a rich environment for processes to communicate with each other
– A mechanism for notifying a process about a particular event occurrence
- 특정 이벤트 발생에 대해 프로세스에 알리는 메커니즘
Signal
– Several mechanisms for passing data among processes
- 프로세스 간에 데이터를 전달하기 위한 여러 메커니즘
Shared memory
Message queue (= message passing)
Pipes
A set of networking facilities
Signals
• A IPC mechanism to notify a process of a particular event
– Can be synchronous (e.g., illegal memory access) or asynchronous (e.g., killed)
- 특정 이벤트를 프로세스에 알리는 IPC 메커니즘
사용자 애플리케이션에서 동기적으로 발생할 수도 있고 비동기적으로 발생할 수도 있다.
• Can be thought as a software interrupt
– Signal is generated by particular events
– Signal is delivered to the process
– A signal handler processes the signal
Every signal has a default handler that kernel runs when handling signal
User-defined signal handler can override the default
: 특정 이벤트에 의해 시그널이 생성되고 이 시그널이 프로세스에 전달되고 시그널 핸들러는 해당 시그널을 처리한다. 핸들러에는 커널에 의해 제공되는 default handler와 이를 오버라이딩하여 사용자가 정의하는 signal handler가 있다.
Signal Handling
• A process can define a signal handler for a signal
• A process can send a signal to other process
– int kill(pid_t pid, int sig); (어떤 시그널을 해당 프로세스에게 보내는 함수)
• The signal handler is invoked on the target process
Signal Handling
$ man 7 signal
Pipes
(A | B : A의 output stream을 B의 input stream으로!)
• A pipe acts as a conduit allowing two processes to communicate
– Pipes can be accessed using ordinary read() and write() system calls as UNIX treats a pipe as a special type of files
– e.g., The output of one process can be directed into the input of another process by using a pipe (I/O redirection)
• Two common types of pipes used on both UNIX/Linux and Windows systems
– Ordinary pipe VS. Named pipe
Pipes
• Ordinary pipes: allowing only one-way communication (= unidirectional) and requiring parent-child relationship between communicating processes
– Producer writes to one end (the write-end of the pipe)
– Consumer reads from the other end (the read-end of the pipe)
– Ordinary pipes are therefore unidirectional
– pipe(int fd[])
: 단방향 통신만 허용, 통신 프로세스 간에 부모-자식 관계가 필요
Ordinary pipe in Linux
Pipes
• Named pipes: (큰 유연성을 제공하는 IPC 매커니즘)
– More powerful than ordinary pipes
– Communication is bidirectional (양방향)
– No parent-child relationship is necessary between the communicating processes (꼭 통신하는 프로세스들이 부모-자식 관계가 아니어도 ㄱㅊ)
– Several processes can use the named pipe for communication (두 개 뿐만 아니라 여러 개가 통신 ㄱㄴ)
– Named pipes stay alive even after process terminates
: 양방향이고, 통신 프로세스간 부모-자식 관계가 필요 X
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Network Structure
UDP vs. TCP
• UDP (User Datagram Protocol)
– Unreliable (패킷이 lost될 수 있음, out-of-order 발생 가능성 O)
Since there are no guarantees of delivery, some packets may become lost
Packets may also be received out-of-order
– Fast transmission (live streaming 등에 사용됨)
• TCP (Transmission Control Protocol)
– Reliable & in-order
Whenever host sends packet, the receiver must send an acknowledgement packet (ACK). If ACK is not received before a timer expires, sender will resend.
(packet이 전달되면, 받는 쪽에서 꼭 ACK를 보내야함 -> 어떤 packet이 loss되었는지 확인 가능)
Sequence numbers in packets allow receiver to sort packets in order and notice missing packets.
– Slower speed than UDP
Communication in Client-Server Systems
• Client-Server Computing Systems
– A specialized distributed system in which server systems satisfy requests generated by clients
• Most network process communications follow a client-server model
– A process on one computer acts as a server, and a process on another computer acts as a client
• Two strategies for communication in client-server systems
– Sockets
– Remote Procedure Calls(RPC)
Sockets
• A socket is defined as an endpoint for communication
– A pair of processes communicating over a network employs a pair of sockets (one for each process)
• Each socket is associated with an unique combination of IP address and port
– The socket 161.25.19.8:1625 refers to port 1625 on host 161.25.19.8
Sockets
• A server opens up a specified port for listening & waits for incoming client requests.
– Once a request is received, the server accepts a connection from the client socket to complete the connection
– All connections must be unique, meaning that they consist of a unique pair of sockets!
• All ports below 1024 are well known, used for standard services
– Servers implementing specific services listen to well-known ports (e.g., Web/HTTP server: port 80, FTP server: port 21, SSH server: port 22)
• A client initiating a request for a connection is assigned a port by its OS.
– This local port has some arbitrary number greater than 1024
Socket Programming in C/C++
• Unix-like OS tries to interact with devices, file, and networks in a uniform fashion
– OS treats them all as part of the file system
• Socket system calls are used for inter-process communication over a network
– 3 steps (connect, send/receive data, terminate), similar to the basic file I/O (open, read/write, close)
• Berkeley Sockets serve to implement this abstraction for network communication
Berkeley Sockets Example (TCP Server)
socket()
• The socket() system call has 3 arguments: Domain, Communication types, Protocol
– Domain of communication
The Internet domain: AF_INET or PF_INET for IPv4, AF_INET6 or PF_INET6 for IPv6
The UNIX domain: AF_UNIX or PF_UNIX or AF_LOCAL or PF_LOCAL
– Types of communication
SOCK_STREAM : TCP/IP
SOCK_DGRAM : UDP/IP
socket()
• A socket provides an integer identifier through which a network communication is going to take place. The newly created socket is analogous to a telephone that has not yet been used to place a call; the socket identifier has not yet been used to connect to anything
bind()
• A server will typically bind the socket, defining the IP and port on which it will listen for connection
– The struct sockaddr_in holds information about how the socket will be used
listen()
• After binding, a server may call listen() to await communication
int listen(int sockfd, int backlog)
-> The 2nd parameter, backlog, describes how many connections can be queued (5 in the example below) while the server is handling another communication. An error value (-1) will be returned to additional clients trying to connect.
accept()
• Once a server has received an incoming connect attempt, it can accept the connection
• accept() returns a second socket on which data will be transmitted. This allows the original socket to continue to listen for additional connections
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen)
connect()
• A client performs a step similar to binding, but instead of listening, it actively makes a call, establishing a connection
– The connect() is used to call the server in an attempt to establish a connection
send() & receive()
• After a connection has been established between the client and server, data can be transmitted and received
• The send() system call takes 4 arguments: Socket identifier, Address pointing to data, Number of bytes to send, Flag setting
ssize_t send(int sockfd, const void *buf, size_t len, int flags)
• The recv() also takes 4 arguments: Socket identifier, Address pointing to data, Max Number of bytes to receive, Flag setting
ssize_t recv(int sockfd, void *buf, size_t len, int flags)
• Both the server and client can execute send() and recv()
• The send() and recv() functions are similar to the fread() and fwrite() functions in that the arguments define an address and a number of bytes, rather than the type of data at the given address
Example Codes for send() & receive()
close()
• Once communication is finished, both the server and client should close their respective sockets
• A close()system call initiates a series of operations within the OS to terminate the connection
– Thus, the socket may still appear in a netstat program listing for several seconds, until the OS has finished the close
Server Example
Client Example
Sockets versus RPCs
소켓을 사용한 통신은 분산 프로세스 간의 저레벨 통신 형식으로 간주된다. 그 이유는 소켓은 통신하는 프로세스 사이에서 구조화되지 않은 바이트 스트림만 교환할 수 있기 때문이다. 이러한 데이터를 구조화하는 것은 클라이언트나 서버 애플리케이션의 몫이다.
RPCs는 조금 더 높은 레벨의 통신 방식이다. 이는 가장 일반적인 형태의 원격 서비스 중 하나로, 네트워크로 연결된 시스템에서 프로세스 간의 프로시저 호출을 추상화하는 방법이다. 이 방법은 클라이언트-서버 컴퓨팅에서도 유용하고 Android에서 동일한 시스템에서 실행 중인 프로세스 간 IPC 형태로 RPCs를 사용한다.
•Communication using sockets (although common and efficient) is considered a low-level form of communication between distributed processes
-Why? … because sockets allow only an unstructured stream of bytes to be exchanged between the communicating threads. It is the responsibility of the client or server application to impose a structure on the data
•Now, lets look a higher-level method of communication: Remote procedure calls (RPCs)
(이미 데이터의 포맷이 정해진 메커니즘 <-> socket)
–One of the most common forms of remote service
–A way to abstract procedure calls between processes on networked systems
–Not only useful for client-server computing, but Android also uses remote procedures as a form of IPC(Inter-process Communication) between processes running on the same system
Remote Procedure Calls
Remote Procedure Calls (RPCs)
•The semantics of RPCs allows a client(= caller) to invoke a procedure on a remote host(= callee/server) as it would invoke a procedure locally
–The RPC system hides the details that allow communication to take place by providing stubs on the server / client sides
• Stubs are proxy objects that abstracts the
actual procedure on the server side
–The Client-side stub locates the server and marshallsthe parameters
Packaging parameters into a form for transmission on network
–The server-side stub receives this message, unpacks the marshalled parameters (unmarshalling), and performs the procedure on the server