物聯網倉儲項目學習遇到的困難【學員筆記】
時間：2018-07-11 來源：未知
1. QT的客戶端，c的服務器之間不好溝通。解決：框架用 QT風格寫(包括信號與槽，QT界面，連接服務器，發送接收等)，數據用c的風格寫，做到與服務器一致。
2. Tcp粘包拆包，收發數據一致，結構體成員類型大小一致。
3. Tcp處理登錄，udp處理發送視頻，導致開線程pthread_create傳參不好傳。Tcp的connfd,udpfd封裝成結構體傳，或者開2個線程。
4. 回收資源時候，關閉connf;但不能關閉udpfd,否則下一次連接傳不了圖片(視頻)了。
5. V4l2框架需要自學，轉碼壓縮算法需要自學。
6. Memcpy之段錯誤: //1在unix上，系統對內存管的比較松，而在linux下，指針可能是指向了一個只讀的內存。buffer = (char*)malloc(outqueue.length);
7. Arm-linux-gcc編譯代碼的時候需要很多頭文件和庫的支持(sqlite3,jpeg)，應該將它們放在相應的位置。
8. -ljpeg一直報錯，cannot found。
通過比對正常的庫文件：libsqlite3.la
# Directory that this library needs to be installed in:
libdir='/home/farsight/libjpeg/lib'
發現libjpeg.la雖然通過arm-linux-gcc交叉編譯了的，但是生成的文件的路徑仍為gcc編譯后libjpeg目錄，而不是自己修改后的armjpeg目錄。
# Directory that this library needs to be installed in:
libdir='/home/farsight/libjpeg/lib'
解決：刪除解壓后的文件，重新解壓，重新arm-linux生成新的文件夾
9. 應該用buf【】裝圖片數據，不應該用char* buf = NULL裝。
10. 應該把攝像頭采集等模塊分開，便于調試。
11. 自學M0模塊(串口函數)，LCD模塊。
12. 服務器循環發圖片，QT客戶端只顯示了一張，因為虛擬機的原因，交叉編譯放在板子上跑，ok
13. 多個客戶端同時訪問的時候出現圖片花的情況，因為會出現搶占隊列資源的情況。把get_picture單獨開一個線程，把取得的圖片放在全局變量buf里，客戶端訪問buf就好，因為客戶端要讀buf，服務器要寫buf，所以得加鎖保護。Udp發送不消耗時間，mencpy消耗時間，避免搶鎖，udp發送后加點延時
14. 客戶端異常卡死，服務端while(1)發送，客戶端無法及時處理，數據太多，導致卡死。???
15. 視頻不流暢，圖片數據太大，占寬帶，設置320*240，QT設置為飽滿縮放scaledContents打鉤
16. 圖片花，QT那邊接受數組定小了。
17. Test_ser模式加不加鎖都OK。True_ser模式加不加鎖兩個客戶端都相互干擾，且段錯誤。
18. True_ser中：pthread_t pid_play;//多客戶端會導致值被修改，導致干擾
19. True_ser中：pthread_cancel(pid_play);//存在暴力取消，導致死鎖的風險
20. True_ser中：因為udp的關系，無法判斷客戶端什么時候退出，客戶端退出時候，服務器依然會發送圖片，浪費。綜上放棄true_ser,采用test_ser。
