linux消息機制

⑴ linux專屬跨進程通信——D-Bus介紹

DBus是Linux平台上專為進程間通信和遠程過程調用設計的統一協議。以下是關於DBus的詳細介紹：

1. 設計目的：

   • 替代傳統進程通信方式：DBus旨在提供一種更高效、更統一的進程間通信機制。
   • 支持系統級與普通進程交流：它特別適用於系統級進程與普通應用程序之間的通信。

2. 技術特點：

   • 二進制消息傳輸：DBus採用二進制格式傳輸消息，避免了文本格式序列化和反序列化的開銷，從而提高了通信效率。
   • 規范維護：其規范由freedesktop.org項目維護，確保了協議的穩定性和兼容性。

3. 匯流排類型：

   • 系統匯流排：針對系統級服務，提供嚴格的許可權管理，確保通信的安全性。
   • 會話匯流排：針對用戶會話內的進程通信，如瀏覽器服務等。

4. 核心概念：

   • 消息：DBus消息包括服務名稱、對象路徑和介面。服務名稱是應用程序的標識符，對象路徑表示對象的層級結構，介面則定義了方法、信號和屬性的名稱。
   • 服務名稱：類似於網路中的IP地址或主機名，用於唯一標識應用程序。
   • 對象路徑：通過斜線開頭的路徑表示，類似於Web服務中的URL，用於定位對象。
   • 介面：定義了方法、信號和屬性的名稱，類似於C++的抽象類或Qt插件中的標識符，用於規定通信的契約。

5. 通信過程：

   • 當一個應用程序連接到DBus守護進程時，它會獲得一個臨時的唯一標識名，類似於網路地址。
   • 應用程序可以通過wellknown name獲得更易記憶和管理的名稱，以便進行通信。

綜上所述，DBus是Linux平台上一種高效、安全的進程間通信協議，通過二進制消息傳輸、嚴格的許可權管理以及清晰的核心概念，為系統級進程與普通進程之間的通信提供了強有力的支持。

⑵ Handler消息機制（一）：Linux的epoll機制

在linux 沒有實現epoll事件驅動機制之前，我們一般選擇用select或者poll等IO多路復用的方法來實現並發服務程序。在linux新的內核中，有了一種替換它的機制，就是epoll。

相比select模型， poll使用鏈表保存文件描述符，因此沒有了監視文件數量的限制 ，但其他三個缺點依然存在。

假設我們的伺服器需要支持100萬的並發連接，則在__FD_SETSIZE 為1024的情況下，則我們至少需要開辟1k個進程才能實現100萬的並發連接。除了進程間上下文切換的時間消耗外，從內核/用戶空間大量的無腦內存拷貝、數組輪詢等，是系統難以承受的。因此，基於select模型的伺服器程序，要達到10萬級別的並發訪問，是一個很難完成的任務。

由於epoll的實現機制與select/poll機制完全不同，上面所說的 select的缺點在epoll上不復存在。

設想一下如下場景：有100萬個客戶端同時與一個伺服器進程保持著TCP連接。而每一時刻，通常只有幾百上千個TCP連接是活躍的(事實上大部分場景都是這種情況)。如何實現這樣的高並發？

在select/poll時代，伺服器進程每次都把這100萬個連接告訴操作系統(從用戶態復制句柄數據結構到內核態)，讓操作系統內核去查詢這些套接字上是否有事件發生，輪詢完後，再將句柄數據復制到用戶態，讓伺服器應用程序輪詢處理已發生的網路事件，這一過程資源消耗較大，因此，select/poll一般只能處理幾千的並發連接。

epoll的設計和實現與select完全不同。epoll通過在Linux內核中申請一個簡易的文件系統(文件系統一般用什麼數據結構實現？B+樹)。把原先的select/poll調用分成了3個部分：

1）調用epoll_create()建立一個epoll對象(在epoll文件系統中為這個句柄對象分配資源)

2）調用epoll_ctl向epoll對象中添加這100萬個連接的套接字

3）調用epoll_wait收集發生的事件的連接

如此一來，要實現上面說是的場景，只需要在進程啟動時建立一個epoll對象，然後在需要的時候向這個epoll對象中添加或者刪除連接。同時，epoll_wait的效率也非常高，因為調用epoll_wait時，並沒有一股腦的向操作系統復制這100萬個連接的句柄數據，內核也不需要去遍歷全部的連接。

當某一進程調用epoll_create方法時，Linux內核會創建一個eventpoll結構體，這個結構體中有兩個成員與epoll的使用方式密切相關。eventpoll結構體如下所示：

每一個epoll對象都有一個獨立的eventpoll結構體，用於存放通過epoll_ctl方法向epoll對象中添加進來的事件。這些事件都會掛載在紅黑樹中，如此，重復添加的事件就可以通過紅黑樹而高效的識別出來(紅黑樹的插入時間效率是lgn，其中n為樹的高度)。

而所有 添加到epoll中的事件都會與設備(網卡)驅動程序建立回調關系，也就是說，當相應的事件發生時會調用這個回調方法 。這個回調方法在內核中叫ep_poll_callback,它會將發生的事件添加到rdlist雙鏈表中。

在epoll中，對於每一個事件，都會建立一個epitem結構體，如下所示：

當調用epoll_wait檢查是否有事件發生時，只需要檢查eventpoll對象中的rdlist雙鏈表中是否有epitem元素即可。如果rdlist不為空，則把發生的事件復制到用戶態，同時將事件數量返回給用戶。

epoll結構示意圖

通過紅黑樹和雙鏈表數據結構，並結合回調機制，造就了epoll的高效。

events可以是以下幾個宏的集合：
EPOLLIN：觸發該事件，表示對應的文件描述符上有可讀數據。(包括對端SOCKET正常關閉)；
EPOLLOUT：觸發該事件，表示對應的文件描述符上可以寫數據；
EPOLLPRI：表示對應的文件描述符有緊急的數據可讀（這里應該表示有帶外數據到來）；
EPOLLERR：表示對應的文件描述符發生錯誤；
EPOLLHUP： 表示對應的文件描述符被掛斷；
EPOLLET：將EPOLL設為邊緣觸發(EdgeTriggered)模式，這是相對於水平觸發(Level Triggered)來說的。
EPOLLONESHOT： 只監聽一次事件，當監聽完這次事件之後，如果還需要繼續監聽這個socket的話，需要再次把這個socket加入到EPOLL隊列里。
示例：

ET(EdgeTriggered) :高速工作模式，只支持no_block(非阻塞模式)。在此模式下，當描述符從未就緒變為就緒時，內核通過epoll告知。然後它會假設用戶知道文件描述符已經就緒，並且不會再為那個文件描述符發送更多的就緒通知，直到某些操作導致那個文件描述符不再為就緒狀態了。(觸發模式只在數據就緒時通知一次，若數據沒有讀完，下一次不會通知，直到有新的就緒數據)

LT(LevelTriggered) :預設工作方式，支持blocksocket和no_blocksocket。在LT模式下內核會告知一個文件描述符是否就緒了，然後可以對這個就緒的fd進行IO操作。如果不作任何操作，內核還是會繼續通知！若數據沒有讀完，內核也會繼續通知，直至設備數據為空為止！

1.我們已經把一個用來從管道中讀取數據的文件句柄(RFD)添加到epoll描述符
2. 這個時候從管道的另一端被寫入了2KB的數據
3. 調用epoll_wait(2)，並且它會返回RFD，說明它已經准備好讀取操作
4. 然後我們讀取了1KB的數據
5. 調用epoll_wait(2)……

ET工作模式：
如果我們在第1步將RFD添加到epoll描述符的時候使用了EPOLLET標志，在第2步執行了一個寫操作，第三步epoll_wait會返回同時通知的事件會銷毀。因為第4步的讀取操作沒有讀空文件輸入緩沖區內的數據，因此我們在第5步調用epoll_wait(2)完成後，是否掛起是不確定的。epoll工作在ET模式的時候，必須使用非阻塞套介面，以避免由於一個文件句柄的阻塞讀/阻塞寫操作把處理多個文件描述符的任務餓死。

只有當read(2)或者write(2)返回EAGAIN時(認為讀完)才需要掛起，等待。但這並不是說每次read()時都需要循環讀，直到讀到產生一個EAGAIN才認為此次事件處理完成，當read()返回的讀到的數據長度小於請求的數據長度時(即小於sizeof(buf))，就可以確定此時緩沖中已沒有數據了，也就可以認為此事讀事件已處理完成。

LT工作模式：
LT方式調用epoll介面的時候，它就相當於一個速度比較快的poll(2)，並且無論後面的數據是否被使用，因此他們具有同樣的職能。

當調用 epoll_wait檢查是否有發生事件的連接時，只是檢查 eventpoll對象中的 rdllist雙向鏈表是否有 epitem元素而已，如果 rdllist鏈表不為空，則把這里的事件復制到用戶態內存中，同時將事件數量返回給用戶。因此，epoll_wait的效率非常高。epoll_ctl在向 epoll對象中添加、修改、刪除事件時，從 rbr紅黑樹中查找事件也非常快，也就是說，epoll是非常高效的，它可以輕易地處理百萬級別的並發連接。

1.減少用戶態和內核態之間的文件句柄拷貝；

2.減少對可讀可寫文件句柄的遍歷。

https://cloud.tencent.com/developer/information/linux%20epoll%E6%9C%BA%E5%88%B6
https://blog.csdn.net/u010657219/article/details/44061629
https://jiahao..com/s?id=1609322251459722004&wfr=spider&for=pc

⑶ linux系統的進程間通信有哪幾種方式

一、方式

1、管道（Pipe）及有名管道（ mkpipe）：

管道可用於具有親緣關系進程間的通信，有名管道克服了管道沒有名字的限制，因此，除具有管道所具有的功能外，它還允許無親緣關系進程間的通信；

2、信號（Signal）：

信號是比較復雜的通信方式，用於通知接受進程有某種事件發生，除了用於進程間通信外，進程還可以發送信號給進程本身。

linux除了支持Unix早期信號語義函數sigal外，還支持語義符合Posix.1標準的信號函數sigaction。

實際上，該函數是基於BSD的，BSD為了實現可靠信號機制，又能夠統一對外介面，用sigaction函數重新實現了signal函數。

3、消息隊列（Message）：

消息隊列是消息的鏈接表，包括Posix消息隊列system V消息隊列。有足夠許可權的進程可以向隊列中添加消息，被賦予讀許可權的進程則可以讀走隊列中的消息。消息隊列克服了信號承載信息量少，管道只能承載無格式位元組流以及緩沖區大小受限等缺點。

4、共享內存：

使得多個進程可以訪問同一塊內存空間，是最快的可用IPC形式。是針對其他通信機制運行效率較低而設計的。往往與其它通信機制，如信號量結合使用，來達到進程間的同步及互斥。

5、信號量（semaphore）：

主要作為進程間以及同一進程不同線程之間的同步手段。

6、套介面（Socket）：

更為一般的進程間通信機制，可用於不同機器之間的進程間通信。起初是由Unix系統的BSD分支開發出來的，但現在一般可以移植到其它類Unix系統上：Linux和System V的變種都支持套接字。

二、概念

進程間通信概念：

IPC—-InterProcess Communication

每個進程各自有不同的用戶地址空間,任何一個進程的全局變數在另一個進程中都看不到所以進程之間要交換數據必須通過內核。

在內核中開辟一塊緩沖區,進程1把數據從用戶空間拷到內核緩沖區,進程2再從內核緩沖區把數據讀走,內核提供的這種機制稱為進程間通信。

(3)linux消息機制擴展閱讀

1）無名管道:

管道是半雙工的，數據只能向一個方向流動；需要雙方通信時，需要建立起兩個管道；只能用於父子進程或者兄弟進程之間（具有親緣關系的進程）。

管道對於管道兩端的進程而言，就是一個文件，但它不是普通的文件，它不屬於某種文件系統，構成兩進程間通信的一個媒介。

數據的讀出和寫入：一個進程向管道中寫的內容被管道另一端的進程讀出。寫入的內容每次都添加在管道緩沖區的末尾，並且每次都是從緩沖區的頭部讀出數據。

2）有名管道：

不同於管道之處在於它提供一個路徑名與之關聯，以FIFO的文件形式存在於文件系統中。這樣，即使與FIFO的創建進程不存在親緣關系的進程，只要可以訪問該路徑，就能夠彼此通過FIFO相互通信（能夠訪問該路徑的進程以及FIFO的創建進程之間）。

因此，通過FIFO不相關的進程也能交換數據。值得注意的是，FIFO嚴格遵循先進先出（first in first out），對管道及FIFO的讀總是從開始處返回數據，對它們的寫則把數據添加到末尾。它們不支持諸如lseek()等文件定位操作。

⑷ 詳解Linux內核通信netlink機制

Linux內核通信netlink機制詳解如下：

一、基本概述 定義：netlink socket是一種用於內核態和用戶態進程之間進行數據傳輸的特殊IPC機制。 實現方式：通過為內核模塊提供一組特殊的API，並為用戶程序提供一組標準的socket介面，實現全雙工通訊連接。

二、特性與優勢 地址族：使用地址族AF_NETLINK。 協議類型：每一個netlink socket在內核頭文件include/linux/netlink.h中定義自己的協議類型。 非同步通訊：提供一個socket隊列來緩沖或平滑瞬時的消息高峰。 動態載入：動態載入模塊中的netlink程序不會與linux內核中的netlink部分產生任何編譯時依賴關系。 多點傳送：支持將消息傳輸給一個netlink組地址，多個進程可以監聽該組地址並接收消息，適用於內核到用戶態的事件分發。 雙工特性：允許內核初始化會話，解決了系統調用和ioctl等單工方式IPC無法由內核主動通知用戶態程序的問題。

三、API介面 用戶空間API： 創建socket：使用socket函數，輸入參數包括地址族AF_NETLINK、類型和協議類型。 發送與接收消息：使用sendmsg和recvmsg函數。 關閉socket：使用close函數。 內核空間API： 創建socket：使用netlink_kernel_create函數，輸入參數包括協議類型和消息處理回調函數。 接收消息：使用skb_recv_datagram函數，處理接收到的消息。 發送消息：需要設置源netlink地址和目的netlink地址，然後發送消息。 關閉socket：使用sock_release函數。

四、消息結構 Netlink消息需要自身的消息頭，為所有協議類型的netlink消息提供一個通用的背景。 用戶空間和內核空間在發送和接收消息時，都需要按照netlink消息頭的格式進行封裝和解封裝。

五、應用場景 Netlink機制廣泛應用於Linux內核與用戶態進程之間的通信，如路由協議、防火牆規則、系統日誌等場景。

⑸ Linux進程間通信的方式有哪些

第一種：管道通信
兩個進程利用管道進行通信時，發送信息的進程稱為寫進程;接收信息的進程稱為讀進程。管道通信方式的中間介質就是文件，通常稱這種文件為管道文件，它就像管道一樣將一個寫進程和一個讀進程連接在一起，實現兩個進程之間的通信。寫進程通過寫入端往管道文件中寫入信息;讀進程通過讀出端從管道文件中讀取信息。兩個進程協調不斷地進行寫和讀，便會構成雙方通過管道傳遞信息的流水線。
第二種：消息緩沖通信
多個獨立的進程之間可以通過消息緩沖機制來相互通信。這種通信的實現是以消息緩沖區為中間介質，通信雙方的發送和接收操作均以消息為單位。在存儲器中，消息緩沖區被組織成隊列，通常稱之為消息隊列。消息隊列一旦創建後即可由多進程共享，發送消息的進程可以在任意時刻發送任意個消息到指定的消息隊列上，並檢查是否有接收進程在等待它所發送的消息。若有則喚醒它，而接收消息的進程可以在需要消息的時候到指定的消息隊列上獲取消息，如果消息還沒有到來，則轉入睡眠等待狀態。
第三種：共享內存通信
針對消息緩沖需要佔用CPU進行消息復制的缺點，OS提供了一種進程間直接進行數據交換的通信方式。共享內存，顧名思義這種通信方式允許多個進程在外部通信協議或同步，互斥機制的支持下使用同一個內存段進行通信，它是一種最有效的數據通信方式，其特點是沒有中間環節，直接將共享的內存頁面通過附接映射到相互通信的進程各自的虛擬地址空間中，從而使多個進程可以直接訪問同一個物理內存頁面。