Multiprocess Communication
Some is not included.
Purpose:
Most times, the program(shell,compiler…) we have seen right now only represents one process, with the following structure:Code, Globals, Heap, Stack, Registers, PC(Program Counter)
However, in complicated cases, we may have one program composed of multiple processes(web server). In web server, the simplist model comprises two processes, one is used for request fetching, another is for local manipulation.
Multiprocess is a way to implement concurrency
. The major purpose is still to boost the efficiency for using CPU.
Example of Web Server
Simplistic Model (Singel Process)
in single process, scheduler is inactiveWebServerProcess{ forever{ wait for incoming request #func 1 read file from disk # send file in response # func 2 } }
After Seperation
Listener{ forever{ wait for incoming request CreateProcess( worker, request ) # activate Worker } } WorkerProcess(request){ read file from disk send response exit }
The idea is to create each worker(process) for a corresponding request to enable the scheduler.
Amount of work on server per request:
- Receive network packet(request)
- Run listner process
- Create worker process -> which can be expensive
- Read file from disk
- Send response
To solve the creation cost, we can do preprocess( create some(max) workers as initialization ).
Listener{ for(i=0; i<MAX_PROCESSES; i++) process[i] = CreateProcess(worker) forever{ wait for incoming request send(request, process[?]) # use Worker } } WorkerProcess[?]{ forever{ wait for message(&request) read file from disk send response exit } }
IPC(Inter Process Communication)
Purpose:
To communicate the info between processes.
Two ways to implement IPC:
- message passing
- By value communication
- Never by reference -> seperation of msg in sender and receiver
- RPC(remote procedural calls)
In Web Server, the IPC is implemented in two fields: inside field(communication between worker and listner) and outside field(communication between client and server).
notice:
in web server, the msg passing is not passed by reference but a new copy created instead. (Indicating memory is not shared)
in OS, the msg passing is implemented through the kernel.
Message Passing
Ways to implement message passing:
- Symmetric Addressing
- Asymmetric Addressing
- Blocking Receive
- Nonblocking Receive
Example of asymmetric addressing:
Listener{
for(i=0; i<MAX_PROCESSES; i++) process[i] = CreateProcess(worker)
forever{
client_pid = receive(msg) #receive from any client(always asymmetric)
msg' = modified msg including client_pid
send (msg', worker_process[?])
}
}
WorkerProcess[?]{
forever{
receive(msg)
read file from disk
send (response, client_pid)
}
}
More examples please refer to the lecture
RPC(Remote Procedural Call)
RPC is based on message passing
Purpose
causes a procedure(function) to execute in a different address space(commonly another computer on a shared network).
RPC Interface
RPC Interface exposes a list of remotely callable procedures, with their signatures(arguments and return values).
Analogy:
RPC Server <-> Export file system
RPC Client <-> Import file system
Problem:
Message passing $\neq$ procedural call
So How to bridge the gap?
Solution: stub library
Stub Library
client and server stub are generated automatically, and they are part of the application
Two message types:
- Call message
- from client to server
- contains argument
- Return message
- from server to client
- contains return values
Mechanism:
Client process communicate with server process through RPC interface(which implementing stub library, the stubs are generated automatically through the compiler
).
- Clinet proc call clinet stub
- client stub goes to kernel and pass the call message
- server stub receive from kernel
- server get proc call and execute
Message Format:
Message needs to include not only the basic arguments(pid,arg0,…) but which procedure is called.
Notice
The mechanism of RPC indicates it’s very inefficient to implement it. SO CAREFUL THINKING BEFORE IMPLEMENT IT.
How does this work?
Automatic stub generation:
- rpcbind
universal addresses to RPC program number mappersudo apt_get install rpcbind
- rpcgen
tool generating remote program interface modules
IPC/LPC/RPC
Reference: https://blog.csdn.net/Cmm_CSDN/article/details/86138330
https://cloud.tencent.com/developer/article/1690556
进程通信:
每个进程各自有不同的用户地址空间,任何一个进程的全局变量在另一个进程中都看不到,所以进程之间要交换数据必须通过内核,在内核中开辟一块缓冲区,进程A把数据从用户空间拷到内核缓冲区,进程B再从内核缓冲区把数据读走,内核提供的这种机制称为进程间通信。
进程间通信(IPC,Inter-Process Communication):
IPC(进程间通信)是指在操作系统中,不同进程之间进行通信和同步的机制。
特指至少两个进程间传送数据或信号的一些技术或方法。进程是操作系统分配资源的最小单位。每个进程都有自己的一部分独立的系统资源,彼此是隔离的。为了能使不同的进程互相访问资源并进行协调工作,才有了进程间通信。这些进程可以运行在同一计算机上或网络连接的不同计算机上。进程间通信技术包括消息传递、同步、共享内存和远程过程调用。 IPC是一种标准的Unix通信机制。
有三种主要类型的进程间通信(IPC):
- Message passing
消息传递(Message Passing)是一种进程间通信(IPC)机制,它允许进程在不共享相同地址空间的情况下进行通信和同步。它通过发送和接收消息来实现。 - 远程过程调用(RPC Reomote Procedure Call):
特指一种隐藏了过程调用时实际通信细节的IPC方法。客户端将调用一个本地方法,而这个本地方法则是负责透明的与远程服务端进行过程间通信。这个本地方法会讲相关参数顺序打包到一个消息中,然后把这个消息发送给服务端提供的方法,服务端的方法会从消息中解出序列化发出来的参数,然后执行,最后仍以同样的方式将方法的返回值发送给客户端 - 共享内存
RPC和MP:
本质上,RPC是基于message passing基础之上衍生出来的。这两者之间最核心的区别在于RPC的适用点主要是用于远程过程或函数调用;因此,在消除RPC的函数或过程调用功能后,RPC便和message passing没有本质区别。
LPC:
LPC(本地过程调用)是Windows操作系统中的一种消息传递机制,用于同一台计算机上的两个进程之间的通信。它类似于广泛使用的标准远程过程调用(RPC)机制,但针对Windows进行了优化。
LPC与消息传递之间的区别:
- 应用范围:LPC仅用于Windows操作系统中,而消息传递是一种通用的IPC机制。
- 优化:LPC针对Windows进行了优化,以提高在同一台计算机上的两个进程之间进行通信的效率。
- 使用方式:LPC不直接通过Windows API提供,而是作为仅供Windows操作系统组件使用的内部机制。而消息传递则可以通过多种编程语言和平台提供的API直接使用。