oven425的部落格

將近半年來,使用socket收資料
從最簡單的block使用到nonblock
也從同步用到非同步
會出現使用的瓶頸都是在很多socket同時要運作的時候
像select就是提供同步的運作
要使用非同步就要使用waitfor...object的api
差別在於系統IO的效率,不需要詢問一次再複製一次
上述兩種方法都有大多使用者的限制
如果同時要收100個socket的資料
有下列幾中方法
1.使用blocking 模式,開100條thread,每一次都直接recv
2.使用nonblocking 模式,開一條thread,用select來判斷哪一個socket有資料進來了
3.使用waitformultiobject,開一條thread,來等資料近來
但一個select 和 一個waitformultiobject最大的等待數目好像都是64
有一個百個就必須要多開thread來解決
但是IOCP並沒有這個限制
另外不管事select或是waitformultiobject都是先去等待有沒有資料
先判斷有沒有資料再去收資料,理論上是做了兩次IO的操作
IOCP也可以避免這個問題

目前的架構如下圖

黃色區塊的部分是自己要建立的程式,其他部分則是硬體
負責收資料的模組式採用IOCP的架構,由C++開發的
要在IOCP裡面算接收逾時還真不知道要怎麼做哩
早期的作法是建立一個map起來紀錄有多少socket在IOCP裡面
然後再開 條thread起來算,multithread就是會有資料同步,況且stl啟動了列舉之後
在還沒列舉完以前,改到容器就掛掉了
所以同步物件其實也多多少少會影響到IOCP的效率

還有一個就是Add Remove這兩大功能也很有問題
這兩個功能其實也牽涉到同步物件,也是我當初搞得很累的地方
禮拜六在高鐵上我想了很久,非同步就是要非同步到底這句話應該對的
目前我的程式Add的功能算得上是非同步,但是remove卻是同步
當初我也採用了很多的同步物件就是要做timeout
如果說把IOCP這個部分獨立出來
讓整個錄影單純化就行了

最後就是令人又愛又恨的非同步IO了
其實我也還沒已掌握整個IO的控制,只知道我delete的記憶體位置會再次出現而已
會造成這樣的原因也跟我使用非同步接收
但卻使用同步關閉的方式有極大的關係
如同MF的書說的,非同步就要非同步到底
像錄影的一開始rtsp的連結以前採用同步的方式
會看到UI整個2頓住,但改成非同以後可就順了
所說停止錄影的部分也要換成非同步的方式
理論上錄影模組只需要一個同步物件來保護旗標,有可能還不用哩
剩下的就是try and error的旅程了