最近在做的乙個小專案，難度不大，但是網路傳輸部分費了一點周折，在這裡把近期的一些經驗教訓總結一下。因為是自己的一點心得，如果有疏漏，後面再補充修正。
程式使用tcp協議傳輸，先epoll_wait（其實連線不多，只是熟悉一下，結果確實學到了東西），然後進行接收。因為tcp有流量控制，會把大的流進行分片，所以一次recv並不能接收全部的資料，剛開始就先接收乙個header，包含了流的長度，然後再迴圈呼叫recv接收整個資料報。後來覺得這樣太繁瑣低階（而且經常發生接收錯誤），就想著怎樣能一次把資料全部接收。
參考了一下專案中的**，呼叫recvfrom就能一次接收，而不用先傳送乙個header，而且這個函式可以用於tcp和udp。立馬覺得這是個神器，嘗試了一下，還是會有接收不完整的情況。思考了一下，專案中是udp，不會進行「分片」，只要在長度那裡填乙個最大值，並且把系統的最大緩衝開大一點就可以了，而我現在是tcp，必然會分片，所以結果就不一樣。
於是又返回recv。查了一下recv這個函式的說明，在flag中有msg_waitall這個選項，可以保證接收完整，但是這樣的話，就必須提前知道資料報的長度。暫時是填了乙個較大的值，不足的資料padding補足，有些浪費。後面想著還是返回原來的老路，先傳送乙個header，然後再msg_waitall進行接收。但是根據最開始的經驗，多次接收的話，偶爾會接收到錯誤的資料報，不知是不是當時沒有處理好，沒有接收完整，導致有可讀的訊號沒有消除，還得驗證一下。
後記：今天驗證了一下，沒有問題。而且驗證了一下epoll的epolloneshot選項，也沒有問題。有乙個奇怪的事情，有一次又是收到大量錯誤的header資訊，修改socket為非阻塞後正常，但是後來不能重現問題了，非常費解。
看了一下專案中**，也是先傳送乙個header(包含長度和flag)，然後進行接收。不過他們呼叫的是ace中reactor等的類，所以**還比較簡潔。
接觸linux好多年了，居然被這麼低階的問題難住，真是難為情啊。。。。。
（後面補一下**）
近期工作經驗總結
最近在android下層做rtp傳送的模組，算是工作以來，最正規的coding mission吧 雖然 不多,但是讓我對於專案的開發略有一些心得.從我的感覺來看,最重要的就是乙個整體的規劃,首先定義與android層的介面,介面呼叫一旦定義下來,那麼後期的coding工作,都將以此為中心,所有功能模...
程式設計經驗總結
學習要選一本好書，不要持有懷疑的態度，把裡面的例子都實現，然後再有思路之後，在做些許的改動，成為自己的風格。讀書有快慢之分，一種是用金錢來換時間 選擇一家培訓機構，或者是求助於人 另一種是用時間來換時間。另外當你有一定的經驗後，就要注意去練習 有思路就要表現在 上，在學校是為了解決道理，知識點，但是...
程式設計經驗總結
在這個行業裡做了快4年了,多少總結了一些東西,成功也許很難複製,但是失敗卻時常被人們重複,我不敢說我做的很好,但是我希望總結出以前失敗的一些教訓,時不時看看,提醒自己以後再也不要犯類似的錯誤.這篇文章會不定期的更新,可能就是簡短的幾句話,但是,也是我實踐和思考的結果.1 程式不會出錯,出錯的肯定是人...