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