最近自己在寫一套伺服器框架，期間遇到很多問題，
對於linux或者windows出錯情況下可以通過錯誤碼獲取錯誤資訊。
為了測試伺服器效能，我在客戶端開了2000個執行緒，這樣每個執行緒
都建立socket和伺服器通訊，連線15個執行緒，再後來的客戶端執行緒
connect過程中會失敗，我另起了乙個客戶端程序進行連線，
還是能連線15個過後才出現問題，初步可以排除伺服器並沒有達到連線
上限，之後在linux上列印該錯誤碼為111，查詢意思為伺服器拒絕客戶端連線。
查詢相關資料是監聽佇列設定為5，只能接受一部分剩餘的由於監聽佇列滿了
就被拒絕了。之後查詢libevent和redis庫的一些監聽佇列大小，設定為128較為
合適，這次同樣會出現一部分客戶端連線失敗，因為監聽佇列總是有限的，
儘管如此，極限的情況下一秒同時連線500多個客戶端還是沒問題。
這個監聽佇列的知識可以介紹下：
這個圖說明tcp是三次握手處理連線和四次握手處理斷開。
listen函式將主動套接字轉換為被動監控套接字，其第二個引數backlog決定了核心的連線快取佇列長度。對於乙個給定的監聽套接字，核心維護兩個佇列：
① 未就緒佇列，存放沒有完成三路握手的連線，監聽套接字收到syn並返回ack+syn，連線處於syn_recv狀態，等待對端傳送ack。如果已完成佇列非滿，
則接收ack，連線握手完成，進入已完成佇列；如果已完成佇列滿則丟棄ack，對端重發ack（對端看到的連線是establised狀態），
若未就緒佇列中的syn_recv等待直到超時還沒進入已完成佇列則丟棄連線（對端不知道，只有在讀寫套接字時才知道）。
② 已完成佇列，存放已經完成三路握手的連線（established），等待accept取走連線。
backlog決定了兩個佇列的長度之和（並不是說兩個佇列之和等於backlog，而是存在個轉換，依賴於具體實現）。
如果未就緒佇列滿則忽略新到來的syn請求，對端重發，如果一直不能進入未就緒佇列則對端connect失敗返回。
除此之外，由於每個客戶端程序我開闢了2000個執行緒，也會報錯errorno為9，意為bad file discirp，錯誤的檔案描述符。
因為linux限制每個程序最多開闢1024個執行緒。
這些都是實際開發中遇到的一些問題，總結出來以便更好地處理以後的問題。
網路程式設計 一些思考
1.在學習網路程式設計的時候，我通過網上的了解，買了不少書，但是在學習的過程中，仍有不少的困惑！我買了以下書籍 unix網路程式設計，卷一 unix網路程式設計，卷二 c 網路程式設計 基於ace框架復用 2.由於我總不能憑空去捏造一些框架，我開始閱讀，一些現有的，網路服務程式的 希望能夠從中獲得靈...
關於Homebrew的一些錯誤總結
今天使用homebrew時出現了一些錯誤，解決之後就記錄了下來 1.brew update failed 描述 error failed while executing git pull解決辦法 解除安裝homebrew，重新安裝。解除安裝 ruby e curl fssl 安裝 ruby e cu...
網路開發的一些總結
1 i o 模型的選擇，epoll就一定好嗎?那是肯定的。這個和select,poll有什麼區別。epoll還有比select,poll先進得地方，就在於將fd得列表維護在核心中，而select,poll是呼叫一次，傳遞一次，這點epoll領先是沒得說得。最主要還是epoll系統呼叫的實現方式採用事...