1. 程式人生 > >將tcp/IP點對點長連線改為udp廣播開發記錄

將tcp/IP點對點長連線改為udp廣播開發記錄

將tcp/IP點對點長連線改為udp廣播,修改原因:tcp/IP長連線會對本地伺服器帶來壓力

udp廣播分為廣播、組播、單播。

 

現在分析採用何種通訊方式

控制沒有采用指定的協議方式,比如http協議,僅是傳送資料包所以接受到資料後都會做解析包處理。如果採用廣播的形式,勢必得在包中指定裝置編號,控制器會一直處理接收的資料,所以這種方式捨棄。

控制器中沒有業務上的不一樣,所以也不採用組播的形式

最後只能採用單播的形式,指定IP指定埠,這樣控制器處理的資料比較少,而且也不用在資料包中對控制器進行編號。本地伺服器只需輪訓指定IP指定埠傳送即可

所以採用udp的單播方式

 

同步問題

由於應用場合問題,得考慮畫面是否同步的原因,影響同步的因素有以下幾方面:

1、控制器從接收到資料到處理顯示出來所用時間   

        裡面有個10ms的延時,這個延時是否可以減短有待考究。預計本部分時間20ms最多了

2、伺服器輪尋傳送資料包的時間

       這個時間沒有了解過,不過對於電腦來說,10ms也是最長時間了。

所以加起來也就30ms的延時,要求重新整理率為30幀的話,已經足夠了。

 

 

同步分為兩種同步,

1、相鄰控制器之間的時間差 

      從上面分析的,這部分頂多不到1ms,所以不用考慮

2、首尾之間的時間差

    從上面考慮,這個時間是量的問題,每個控制器從接收到資料到驅動顯示,幾乎時間相差不大,本地伺服器輪詢傳送資料包時間估計不到1ms就算我給10Ms一百個控制器1000ms,估計有問題了

如果同步有問題,解決同步的方法

控制器在上電和半夜的時候進行時間查詢,查詢網際網路時間,進行本地時間校對, 本地開一個1ms定時器進行計時,資料包中加入何時重新整理資料包的時間

不知道能不能用上,為了保險,在資料包中加入是否啟動時間重新整理功能

 

推力不會用到,同步的時間是精確到秒。本地要求重新整理到30幀的話,差不多30ms重新整理一次,30ms內不可能指定時間

資料包格式

為了可擴充套件,資料包增加包型別

包頭		資料長度	資料型別	資料	校驗位				
0XFFFFFF	0XFFFFFF	0X****			0X****				
									
									
資料型別	功能	資料							
		畫素顏色	畫素顏色	畫素顏色	畫素顏色				
0x01	全部改變資料,不重新整理	0X******	0X******	……	0X******				
		位置	畫素顏色	位置	畫素顏色				
0X02	改變指定位置資料,不重新整理	0X****	0X******	0X****	0X******				
		畫素顏色							
0x03	改變所有位置顏色一樣,不重新整理	0X******							
		開始位置	終止位置	畫素顏色	畫素顏色	畫素顏色	開始位置	終止位置	畫素顏色
0x04	改變區間位置顏色,不重新整理	0xf***	0xf***	0x******	0x******	0x******	0x0***	0x0***	0x******
									
0x05	重新整理命令	可以通過廣播發出來							
		畫素顏色	畫素顏色	畫素顏色	畫素顏色				
0x11	全部改變資料,並重新整理	0X******	0X******	……	0X******				
		位置	畫素顏色	位置	畫素顏色				
0X12	改變指定位置資料,並重新整理	0X****	0X******	0X****	0X******				
		畫素顏色							
0x13	改變所有位置顏色一樣,並重新整理	0X******							
		開始位置	終止位置	畫素顏色	畫素顏色	畫素顏色	開始位置	終止位置	畫素顏色
0x14	改變區間位置顏色,並重新整理	0xf***	0xf***	0x******	0x******	0x******	0x0***	0x0***	0x******

具有區域性重新整理,指定重新整理等功能,減少資料量,新增只重新整理資料和重新整理資料和重新整理畫面功能還有單獨重新整理介面命令,這樣通過廣播發出重新整理介面的命令,可以改善多個控制器畫面的不同步問題。