溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
C/C++ 協程用于服務器的實現方法？這個問題可能是我們日常學習或工作經常見到的。希望通過這個問題能讓你收獲頗深。下面是小編給大家帶來的參考內容，讓我們一起來看看吧！
有同步式服務器編程的順序思路，便于功能設計和代碼調試——我使用了 libco 中的協程部分
有異步 I/O 的性能——我使用了 libevent 中的 event I/O apache php mysql
結構上，就是將 libco 和 libevent 兩者的功能結合起來，所以我把我的工程，命名為 libcoevent，意為 “基于 libevent 的同步協程服務器編程框架”。名字中 co 的意思并不代表 libco，而是 coroutine。
編程語言上，我選擇的是 C++，主要是因為 libco 只支持基于 x86 或 x64 架構的 Linux，而這樣的架構，基本上都是 PC 機，或者是資源不缺、性能也不錯的嵌入式系統，上 C++ 完全沒有問題。本文解釋代碼實現的原理。
如果要使用該工程，請在鏈接選項中加入 -lco -levent -lcoevent 三個選項。
類的基本繼承關系圖如下：
在實際調用中，只有處于繼承關系樹的葉子結點上的類才會被實際使用到，其他類均視為虛類。
各類的實例在程序運行中是有從屬關系的，除了作為頂層的 Base 類之外，其他樹葉類都需依附于其他的類所在的運行環境中才能執行。從屬關系圖如下：
Base 類提供最基本的運行環境，并管理 Server 對象；
Procedure 對象管理 Client 對象。在圖中體現為 Server 和 Session 對象均管理 Client 對象。
Server 對象由應用程序創建并初始化到 Base 對象中運行。當服務器結束或當其從屬的 Base 對象銷毀時，可配置自動銷毀 Server 對象。
Session 對象由處于會話模式（session mode）的 Server 對象自動創建，并調用應用程序指定的程序入口運行；當會話結束時（函數調用 return）或其從屬的 Server 對象服務結束時，由 Server 對象自動銷毀。
Client 對象由應用程序調用 Procedure 對象的接口創建，用于與第三方服務交互。應用程序可提前調用接口要求銷毀 Client 對象，也可以待 Procedure 服務結束時自動統一銷毀。
Base 類用于運行 libcoevent 的各個服務。每個 Base 類的實例應對應著一個線程，所有的服務以協程的方式在 Base 實例中運行。從上圖可知，Base 類包含一個 libevent 庫的 event_base 對象和本協程庫的一系列 Event 對象。
Event 類其實是借用了 libevent 的 struct event 名稱，因為每一個 Event 類的實例，對應著 libevent 的一個 event 對象。我們需要關注的重點，是 Procedure 和 Client 類。
Procedure 類有兩個關鍵特點：
每個對象都擁有一個 libco 協程，即擁有自己獨立的上下文信息，可以用于編寫一個獨立的服務器過程（procedure）；
Procesure 的子類可以創建 Client 對象與第三方服務器通信和交互。
Procedure 類擁有兩個子類，分別是 Server 和 Session。
Server 類由應用程序創建并初始化到 Base 對象中運行。Server 類有三個子類：
SubRoutine：實際上不作為任何服務器程序，但提供了最基本的 sleep() 函數，并支持 Procedure 類的創建 Client 對象的功能，因此應用程序可以用來作為臨時創建或常駐的內部程序來使用。
UDPServer：應用程序創建并初始化 UDPServer 對象后，程序會自動綁定到一個數據報 socket 接口上。應用可以通過在網絡接口中收發數據包來實現網絡服務。UDPServer 同時提供普通模式和會話模式。
TCPServer：應用程序創建并初始化 TCPPServer 對象后，程序會自動綁定并監聽流 socket。TCPServer 只支持會話模式。
所謂的 “普通模式”，也就是應用程序注冊 Server 對象的入口函數，并且由應用程序操作 Server 對象的行為。
所謂的 “會話模式”，指的是 UDPServer 或 TCPServer 對象，在接收到傳入數據后，自動區分客戶端，并單獨創建 Session 對象進行處理。每個 Session 對象只服務于一個客戶端。
Session 對象不能由應用主動創建，而是由處于會話模式的 Server 類自動按需創建。Session 對象的特點是，只能與單一一個客戶端（相比起 UDPServer 對象而言）進行通信，因此沒有 send() 函數，只有 reply() 。
在頭文件 coevent.h 聲明的 Session 類及其子類均為純虛類，目的是防止應用程序顯式地構建 Session 對象并隱藏實現細節。
Client 對象由 Procedure 對象創建，并且由 Procedure 對象進行回收。Client 對象的作用是主動向遠程服務器發起通信。由于從客戶-服務結構的角度，這個動作屬于客戶端，所以命名為 Client。
Client 的子類中比較特別的是 DNSClient 類，這個類的存在是為了解決在異步 I/O 中的 getaddrinfo() 阻塞問題。DNSClient 的實現原理請參見代碼和我之前的文章《DNS 報文結構和個人 DNS 解析代碼實現》。
而對于 DNSClient 類而言，具體實現原理，就是封裝了一個 UDPClient 對象，通過該對象完成 DNS 報文的收發，并在類中實現報文的解析。
UDPServer 類普通模式的原理，就是一個非常典型的基于 libevent 的同步協程服務器框架。其代碼實現中，核心功能就是以下幾個函數：
_libco_routine()，協程的入口函數，使用這個函數，轉化成為 liboevent 的統一服務入口函數
_libevent_callback()，libevent 時間回調函數，在這個函數里，實現協程上下文的恢復。
UDPServer::recv_in_timeval()，數據接收函數，在這個函數中，實現關鍵的數據等待功能，同時實現了協程上下文的保存
上述三個函數的代碼總量，加上空行也不超過 200 行，我相信還是很容易看明白的。以下具體解釋實現原理：
正如前文所說，我使用的是 libco 作為協程庫。協程對于應用程序是透明的，但是對于庫的實現而言，這才是核心。
下面解釋一下 libco 的協程功能所提供的幾個接口（libco 的文檔數量簡直 “感人”，這也是網上經常被吐槽的……）：
Libco 使用結構體 struct stCoRoutine_t * 保存協程，通過調用 co_create() 可以創建協程對象；使用 co_release() 銷毀協程資源。
創建了協程之后，調用 co_resume() 可以從協程函數的開頭開始執行協程。
當協程到了需要交出 CPU 使用權的時候，可以調用 co_yield() 釋放協程、切換掉上下文。調用之后，上下文會恢復到上一個調用 co_resume() 的協程中。調用 co_yield() 的位置可以視為一個 “斷點”。
恢復協程和創建協程所用的函數都是 co_resume()，調用該函數，將當前堆棧切換為指定協程的上下文，協程會從上文提到的 “斷點” 恢復執行。
從上一小節可以看到，我們使用到的 libco 協程功能函數中，雖然包含了協程的切換函數，但什么時候切換、切換之后 CPU 如何分配，這是我們需要實現并封裝起來的工作。
創建和銷毀協程的時機，自然就是在 UDPServer 類初始化和析構的時候。下文重點解析進入、暫停和恢復協程的操作：
進入 / 恢復協程的代碼，是在 _libevent_callback() 中，有這么一行：
// handle control to user application co_resume(arg->coroutine);
如果當前協程還沒有被執行過，那么執行了這句代碼之后，程序會切換到創建 libco 協程時指定的協程函數開始執行。對于 UDPServer，也就是 _libco_routine() 函數。這個函數非常簡單，只有三行：
static void *_libco_routine(void *libco_arg)
{
struct _EventArg *arg = (struct _EventArg *)libco_arg;
(arg->worker_func)(arg->fd, arg->event, arg->user_arg);
return NULL;
}通過傳入參數，將 libco 回調函數轉換為應用程序指定的服務器函數執行。
但是如何實現第一次的 libevent 回調呢？這還是很簡單的，只需要在調用 libevent 的 event_add()時，將超時時間設置為 0 即可，這會導致 libevent 事件立即超時。通過這個機制，我們也就實現了在 Base 運行之后立即執行各 Procedure 服務函數的目的。
在什么時候調用 co_yield是本協程實現的重點，調用 co_yield 的位置，是一個可能會導致上下文切換的地方，也是將異步編程框架轉換為同步框架的關鍵技術點。這里可以參照 UDPServer 的 recv_in_timeval() 函數。函數的基本邏輯如下：
其中最重要的分支，就是對 libevent 事件標志的判斷；而最重要的邏輯，就是 event_add() 和 co_yield() 函數的調用。函數片段如下：
struct timeval timeout_copy;
timeout_copy.tv_sec = timeout.tv_sec;
timeout_copy.tv_usec = timeout.tv_usec;
...
event_add(_event, &timeout_copy);
co_yield(arg->coroutine);這里，我們把 co_yield() 函數理解為一個斷點，當程序執行到這里的時候，CPU 的使用權會被交出，程序回到調用 co_resume() 的上一級函數手中。這個 “上一級函數” 究竟是哪里呢？實際上就是前文提到的 _libevent_callback() 函數。
從 _libevent_callback() 的角度來看，程序會從 co_resume() 函數返回，并且繼續往下執行。此時我們可以這么理解：協程的調度，實際上是借用了 libevent來進行的。這里我們要關注一下 co_resume() 上方的幾句：
// switch into the coroutine
if (arg->libevent_what_ptr) {
*(arg->libevent_what_ptr) = (uint32_t)what;
}這里將 libevent 事件 flag 值傳遞給了協程，而這是前文進行事件判斷的重要依據。當時間到來，_libevent_callback() 會在下面調用 co_resume() 的位置，將 CPU 使用權交回給協程。
除了 ci_yield() 之外，協程函數調用 return 也會導致從 co_resume() 返回，所以在 _libevent_callback() 中，我們還需要判斷協程是否已經結束。如果協程結束，那么就應當銷毀相關的協程資源了。參見 if (is_coroutine_end(arg->coroutine)) {...} 條件體內的代碼。
在本工程的實現中，提供了被稱為 “會話模式” 的一個服務器設計模式。會話模式指的是 UDPServer 或 TCPServer 對象，在接收到傳入數據后，自動區分客戶端，并單獨創建 Session 對象進行處理。每個 Session 對象只服務于一個客戶端。
對于 TCPServer 而言，實現上述的功能比較簡單，因為監聽一個 TCP socket 之后，當有傳入連接的時候，只要調用 accept()，就可以獲得一個新的文件描述符，為這個文件描述符創建一個新的 Server 的子類就行了——這就是 TCPSession 類。
但是 UDPServer 就比較麻煩了，因為 UDP 不能這么做。我們只能自行實現所謂的 session。
我們需要實現 UDPSession 類的如下效果：
類調用 recv 函數時，只會接收到對應的遠程客戶端發來的數據
類調用 send 函數（實際實現是 reply()）時，可以使用 UDPServer 的端口進行回復
在工程中，UDPSession 是抽象類，實際實現是 UDPItnlSession。但是準確而言，UDPItnlSession 的實現，密切依賴于 UDPServer。這一部分，可以參照 UDPServer 的 _session_mode_worker() 函數中的 do-while() 循環體代碼。程序思路如下：
UDPServer 維護一個 UDPSession 字典，以遠程 IP + 端口名的組合作為 key。
當數據到來時，判斷遠程 IP + 端口的組合是否在字典中，如果在，那么就把數據復制給對應的 session；如果不存在，則創建 session
復制數據的代碼，參見 UDPItnlSession 類的 forward_incoming_data() 函數實現。
發送數據其實就很簡單，直接對 UDPServer 的 fd 進行 sendto() 就可以了。
對于 session mode 的 Server 對象，代碼中提供了一個可以由其 session 調用的、要求 server 退出并銷毀資源的函數：quit_session_mode_server()。實現原理是向 server 觸發一個 EV_SIGNAL 事件。對于普通的 I/O 事件而言，這是不應當出現的，我們這里活用來作為退出信號。如果 server 發現了這個信號，則觸發退出邏輯。
本工程的示例代碼分為 server 和 client 兩部分，其中 server 用到了 libcoevent，而 client 只是使用 Python 寫的簡單程序。本文就不說明 client 部分的代碼了。
Server 的代碼，分別針對 Server 類的三個子類做了應用示例。使用了包括空行、調試語句、錯誤判斷等在內的邏輯，僅使用不到 300 行，就實現了一個過程和兩個服務。應該說，邏輯還是很清晰的，而且也節省了大量代碼。
通過函數 _simple_test_routine()，展示了一個一次性的線性網絡邏輯。程序中，routine 首先創建了一個 DNSClient 對象，向默認域名服務器請求了一個域名，然后 connect() 該服務器的 80 端口。成功后，直接返回。
這個函數展示了 SubRoutine 的使用場景，以及 Client 對象的使用方法，特別是 DNSClient 的簡易使用方法。
UDPServer 的入口函數是 _udp_session_routine()，功能是為客戶端提供域名查詢服務。Clients 發送一段字符串作為待查詢域名，然后 server 通過 DNSClient 對象請求后，將查詢結果返回給客戶端。
這個函數展示了 UDPSession 對象和 DNSClient 的（比較復雜和完整的）使用方法。
入口函數是 _tcp_session_routine()，邏輯比較簡單，主要是展示 TCPSession 的用法。
感謝各位的閱讀！看完上述內容，你們對C/C++ 協程用于服務器的實現方法大概了解了嗎？希望文章內容對大家有所幫助。如果想了解更多相關文章內容，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
