Boost asio 連接池問題

joepayne

想建立一個TCP 連接池，所有的請求全部共享這些TCP連接。很久沒有接觸網絡編程了，對ASIO也是第一次接觸，不知道這樣做可不可以
場景：
有K級別的并發(fā)線程，每個線程需要間斷性地發(fā)請求(比方說每隔200000ns)，需要重復10-50次左右，服務端處理每次請求的時間大概在3-10ms，客戶端對socket的讀寫數據都很小，但都是同步的，要求請求的吞吐量盡可能地大

初步想法：
請求的量比較大，每次請求new 一個tcp連接感覺不大現實，所以想預先建立一個TCP連接池，并保持連接是激活狀態(tài)，每次發(fā)請求里直接從池子里取出一個連接，然后直接寫數據，讀數據，之后將連接返回池子

大神們給給意見，如果想用asio這種跨平臺的上層網絡庫來寫一個這樣的連接池應該怎么寫，如果有大神寫過，不知道能否借鑒學習一下=）

------- update ----------
UC網站的頁面還是N年前的樣子，唯一沒變的是仍然是大神們的常聚地，=）

附加為我的測試代碼，好像有問題，大神們給看看，感謝！


------- update ----------
根據業(yè)內幾個大哥的反饋及提示，已經實現了一個看起來似乎可行的簡單的服務端多線程異步/客戶端同步的一個網絡接口，還沒有經過嚴格的測試驗證就先不附代碼了。這個帖子也會持續(xù)更新，還在跟大哥們學習，補充這方面的東西  

sxcong

沒那么復雜
幾千個并發(fā)線程，并不需要開幾千個連接。在客戶端，你把要發(fā)送的東西放到一個隊列里，開個線程池向外發(fā)就是了。
服務器端更簡單，linux 下直接epoll，偵聽一個線程，accept之后放到隊列中。有事件就read，讀到的數據也是放到一個隊列里，由工作線 程去做。
你這個簡單的場景下，如果非要用框架，感覺poco，libevent, libev都不錯。epoll熟的話，直接寫最好。

Fixend

你的需求是同步socket，這個簡單啊，如果是異步的需求會復雜很多。
首先你要知道怎么建立連接，發(fā)送和接收數據。
Daytime.1 - A synchronous TCP daytime client
Daytime.2 - A synchronous TCP daytime server

然后用一個類來維護這些連接，需要用的時候獲取，用完返還到池里，記得加鎖，這個類基本所用對外的接口都是需要加鎖的。

1. boost::recursive_mutex::scoped_lock lock(mutex_)

復制代碼

當然，你還可以增加動態(tài)增加/減少連接數量的機制，自動重連之類的機制。

joepayne

回復 3# sxcong

感謝回復！

把要發(fā)送的東西放到一個隊列里，開個線程池向外發(fā)就是了

因為客戶端是在線的實時請求，不管是線程內的多個請求還是不同線程之間的請求，發(fā)送的內容不是一樣的，所以這里我不大明白把要發(fā)送的東西放到一個隊列里，再開線程發(fā)是解決什么問題？

然后，想盡可能地做到跨平臺，因為服務可能部署在云上也可能部署在內網，如果只是單純epoll/select/kqueue那套東西這個事情就簡單了，所以想盡量能通用一些。

另外我把寫的demo代碼帖出來了，UC的格式好像有些凌亂，我放附件了，我的做法大概就是用一個queue來把連接維護起來，需要調request的時候就從queue里面取一個連接，進行阻塞式的寫讀操作，然后歸還連接。多多指點啊-）

joepayne

回復 4# Fixend


感謝回復！

扯些閑話，5年前寫系統(tǒng)編程的時候，記得當時的開發(fā)環(huán)境是UNIX，當時用的C++版本還是C0*，用的接口也都是posix接口，當下生產環(huán)境需要自己部署自己的服務，對外提供接口，需要跨平臺，跨語言（這個需要用第三方序列化工具），對性能有一定要求，如果回頭還是用posix那堆接口開發(fā)成本太大，而且沒法跨平臺啊，自身再去仔細擼那些代碼有些力不從心了，asio感覺挺上層的，也跨平臺，所以想就用它封裝一下算了�，F在回頭看C++生態(tài)圈子的東西感覺整個世界都變了，

附件有我的測試代碼，代碼中服務端開了10個線程，異步模型；客戶端開了三個線程，每個線程重復發(fā)起了5個請求。最終，出現 "Broken pipe" "Socket is not connected" 等錯誤，感覺是在復用的時候連接就已經斷了，導致的錯誤。我個人認為需要加持長連接，保持激活狀態(tài)，只是不知道，客戶端跟服務端怎么去配置。

Fixend

回復 6# joepayne

跟多年前比區(qū)別不大，asio很多年前就有了，再之前還有ACE.這些東西10多年前就很多人用。

你這個斷開是你自己關掉的，你服務器寫不對，都delete掉socket了。

1.     void onResponseSent(const boost::system::error_code& ec,
   
2.                     std::size_t bytes_transferred) {
   
3.           if (ec != 0) {
   
4.             std::cout << "Error occured! Error code = "
   
5.               << ec.value()
   
6.               << ". Message: " << ec.message();
   
7.           }
   
8.           onFinish();
   
9.     }
   
10.     // Here we perform the cleanup.
    
11.     void onFinish() {
    
12.           delete this;
    
13.     }

復制代碼

Fixend

回復 5# joepayne

把要發(fā)送的東西放到一個隊列里，再開線程發(fā)是解決什么問題？  

這個是異步的常規(guī)做法，隊列相當于發(fā)送緩沖。如果你用asio的異步發(fā)送接口，肯定要加發(fā)送緩沖的，
否則，你多線程同時異步發(fā)送，會出問題的，只能在緩沖中排隊進行發(fā)送。

joepayne

回復 7# Fixend

對，系統(tǒng)底層的東西基本沒多少變化，只是C++標準換血了，特性也多元化了

這個地方我也想到了，是server-side主動關閉的，但是，這里我只是把service線程的資源給釋放掉了，其中的socket只是一個shared_ptr，其連接這里并沒有釋放掉。

1. private:
   
2.         std::shared_ptr<asio::ip::tcp::socket> m_sock;
   
3.         std::string m_response;
   
4.         asio::streambuf m_request;

復制代碼

socket只是在

1. void InitAccept() {
   
2.      std::shared_ptr<asio::ip::tcp::socket> sock = std::make_shared<asio::ip::tcp::socket>(m_ios);
   
3.      m_acceptor.async_accept(*sock.get(),
   
4.                                           [this, sock](const boost::system::error_code& error) {
   
5.                                                           onAccept(error, sock);
   
6.                                                    }
   
7.                                         );
   
8.         }

復制代碼

這個函數執(zhí)行完才斷開的，是吧？那這里我應該再維護一個socket池子？

joepayne

回復 8# Fixend


噢，明白。我這里是同步的應該不用緩沖了