999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

sACN協(xié)議支持下的舞臺燈光控制網(wǎng)絡的研究

2012-07-25 11:06:12李笳平卜方玲孟凡榮
計算機工程與設計 2012年7期

李笳平,卜方玲,孟凡榮,劉 航

(1.武漢大學 電子信息學院,湖北 武漢430079;2.中國科學院研究生院 光電研究所,北京100190)

0 引 言

20世紀80年代中期,美國劇場技術(shù)協(xié)會提出了只要一對線路就可以傳輸512路燈光亮度數(shù)據(jù)的DMX512(digital multiplex with 512pieces of information)協(xié)議標準[1],圖1是傳統(tǒng)的DMX512協(xié)議舞臺燈光控制模型[2]。隨著舞臺燈光控制的規(guī)模不斷擴大,而且為了追求更絢麗的效果而使用如換色器、煙霧器、吊掛器等其它類型設備,使得燈光控制系統(tǒng)需要提升規(guī)模和性能。以以太網(wǎng)為代表的網(wǎng)絡技術(shù)不僅具有可擴展性、傳輸速度快、規(guī)模大等優(yōu)點,而且網(wǎng)絡配置簡單[3-4],因此基于網(wǎng)絡的燈光控制協(xié)議如ACN、sACN正在被研究和發(fā)展[5-6]。本文在研究和實現(xiàn)sACN協(xié)議的基礎上,分析了共享介質(zhì)以太網(wǎng)服務端發(fā)送sACN數(shù)據(jù)包可支持的客戶端規(guī)模。由于sACN協(xié)議服務器端(sACN燈光控制臺)依靠連續(xù)不停的發(fā)送燈光數(shù)據(jù)以避免丟包,導致網(wǎng)絡負載加重,不利于網(wǎng)絡擴展,為了提高網(wǎng)絡資源利用率,而且為了在舞臺燈光控制中sACN服務端能監(jiān)測到sACN客戶端 (接收燈光數(shù)據(jù)的調(diào)光模塊)的數(shù)據(jù)收發(fā)狀態(tài)和設備性能狀態(tài)等有用信息,本文設計了一種sACN舞臺燈光應答幀格式,用于客戶端在收到sACN協(xié)議數(shù)據(jù)后回復應答幀給服務端。如果大量的客戶端向服務端回復應答幀,在傳統(tǒng)的共享介質(zhì)以太網(wǎng)中,會產(chǎn)生信號沖突,CSMA/CD機制在網(wǎng)絡負載重時會導致網(wǎng)絡延時增大,不能滿足舞臺燈光控制的實時性要求[7],因此,本文提出了一種順序應答機制的沖突避免機制,并設計了以交換機為中心節(jié)點的星型舞臺燈光控制網(wǎng)絡,達到在多客戶端回復應答幀時網(wǎng)絡延時最小化的目的,提高舞臺燈光控制網(wǎng)絡的數(shù)據(jù)傳輸和資源利用的效率。

1 基于sACN協(xié)議數(shù)據(jù)包的網(wǎng)絡時延分析

1.1 sACN協(xié)議

sACN (streaming ACN)協(xié)議標準是由美國娛樂服務和技術(shù)協(xié)會 (ESTA)在制定 ACN (architecture control network)協(xié)議后制定的介于DMX512和ACN之間的過渡協(xié)議。它通過使用ACN整體協(xié)議中的一部分用于在TCP/IP網(wǎng)絡中傳輸DMX512數(shù)據(jù)包,利用單播或多播地址傳輸數(shù)據(jù)鏈 (universe)來控制調(diào)光器。sACN協(xié)議在UDP/IP上定義了三層結(jié)構(gòu)用于封裝DMX512數(shù)據(jù)包,分別是:DMP Layer、Framing Layer、Root Layer。如圖2所示為sACN協(xié)議模型圖。

圖2 sACN協(xié)議層次結(jié)構(gòu)

sACN協(xié)議數(shù)據(jù)包基本長度為638字節(jié),其中包括513字節(jié)的DMX512燈光數(shù)據(jù)和125字節(jié)的報頭數(shù)據(jù)。

1.2 sACN數(shù)據(jù)包傳輸時延分析

時延是指一個報文或分組從一個網(wǎng)絡的一端傳送到另一個端所需要的時間,它包括了發(fā)送時延、傳輸時延 (傳播時延包含在內(nèi))、節(jié)點處理時延、排隊時延 (即等待時延)[8]。一般情況下,發(fā)送時延與報文長度有關(guān),報文越長發(fā)送時延越大。本文所研究的時延限制在局域網(wǎng)中,所指的時延是局域網(wǎng)中點與點之間的時延。

發(fā)送時延——Tsend;傳輸時延——Tts;處理時延——Trev;排隊時延——Twait,網(wǎng)絡時延數(shù)學表達式為

首先分析舞臺燈光控制網(wǎng)絡的服務端發(fā)送sACN協(xié)議數(shù)據(jù)包可支持的客戶端數(shù)量。sACN協(xié)議中,在UDP/IP、數(shù)據(jù)鏈路層、物理層之上的三層——DMP Layer、Framing Layer、Root Layer的數(shù)據(jù)包長度為638字節(jié),UDP、IP、數(shù)據(jù)鏈路層都有各自的封裝頭長度。定義應用層 (即sACN協(xié)議上3層)一路數(shù)據(jù)包長為LsACN,UDP頭長為LUDP,IP頭長為LIP,數(shù)據(jù)鏈路層頭長為LDLL(data link layer)這些量的單位都是字節(jié) (Byte),則在網(wǎng)絡上傳輸?shù)臄?shù)據(jù)包總長為

式 (1)是針對一路數(shù)據(jù)的,而當在同一以太網(wǎng)線上傳輸n路sACN數(shù)據(jù)時,公式為

當n為1時,網(wǎng)上傳輸Ltotal長度的一幀的時間為τtotal,網(wǎng)絡的帶寬為V,單位為Mbps(這里V是指在局域網(wǎng)情況下,一般是10/100Mbps,常用的是100Mbps,如果是在公網(wǎng)上,V是受電信運營商限制的),所以在網(wǎng)絡帶寬V完全利用的情況下,得到最小傳輸時間τ,關(guān)系為 (式 (4)乘以8是由于1Byte=8bit)

在程序設計中,應用層的數(shù)據(jù)包發(fā)送間隔可以通過代碼控制 (如sleep()函數(shù)),定義為Tival(interval,單位為ms)。根據(jù)DMX512協(xié)議燈光照明標準定義,DMX512數(shù)據(jù)同一路數(shù)據(jù) (如相同的接收機接收到第n路數(shù)據(jù)和下一次接收到第n路數(shù)據(jù))之間傳輸時延最大為22.5ms(用T表示,單位為ms),最小傳輸速率為250kbps(用vmin)。Tival通過程序控制,范圍為 [0,22.5)。

發(fā)送時延為Tival,傳輸時延為傳輸Ltotal長度的時間(這里不考慮傳播時延,因為傳播時延太小,可以忽略不記)。理想情況下,在不考慮排隊時延 (不考慮競爭的情形下)和接收處理時延 (CPU處理速度非常快和緩存非常大,此處時延忽略不記)的情況下,研究達到T標準(22.5ms)的數(shù)據(jù)發(fā)送服務器所支持的理想最大傳輸路數(shù)(n)。理想情況下不等關(guān)系為

由于在傳輸中sACN數(shù)據(jù)包長度相比整個包的IP頭大很多,為簡單起見,在不考慮LUDP、LIP、LDDL報頭長度的情況下,有

定義傳輸LsACN長度的時間為τ,有

式 (7)代入不等式 (6)有

對于通常使用的以太網(wǎng)局域網(wǎng),V為100Mbps,又LsACN為638Byte,代入得到τ=51.04μs,為使n取得最大值,取Tival為0,不等式取等號,有

又T為22.5ms,所以得到n的最大值為440.83,舍去小數(shù)點后值為440。對于普通的支持256個IP地址的以太網(wǎng)來說,除去數(shù)據(jù)服務器和路由器 (或集線器、交換機等),最大支持254個數(shù)據(jù)接收機,從440這個結(jié)果來看支持254個接收機是可以達到延時要求,但這只是在理想情況下,因為并沒有考慮的底層的這些頭長以及排隊時延這種重要因素,擁塞對網(wǎng)絡帶寬又有很大限制,V是受其影響的,滿足要求的數(shù)據(jù)接收機的數(shù)量事實上小于440這個上限,但是可以支持254個數(shù)據(jù)接收機。

1.3 舞臺燈光控制網(wǎng)絡架構(gòu)設計

從1.2節(jié)的分析可知,對于支持256個IP地址的共享介質(zhì)的總線型以太網(wǎng)而言,雖然可以滿足服務端所支持的sACN協(xié)議數(shù)據(jù)包傳輸客戶端數(shù)量要求,但是,在舞臺燈光控制中,出故障的節(jié)點需要快速定位并進行處理,以減小設備性能損壞對燈光控制的影響,總線型網(wǎng)絡的故障診斷和隔離是比較困難的。

此外,sACN協(xié)議在數(shù)據(jù)傳輸中依靠不停的發(fā)送燈光數(shù)據(jù)來抑制數(shù)據(jù)丟包造成的影響,但是這種數(shù)據(jù)傳輸模式造成網(wǎng)絡負載加重,不利于網(wǎng)絡擴展。本文針對sACN協(xié)議的缺點對其功能進行了擴展,設計了舞臺燈光應答幀。客戶端回復應答幀的過程中,總線型網(wǎng)絡使用的CSMA/CD機制會導致沖突過多,對實時性要求很高的舞臺燈光系統(tǒng)來說是不能容忍的。

相比總線型網(wǎng)絡,星型網(wǎng)絡不僅和總線型以太網(wǎng)一樣可以支持sACN協(xié)議數(shù)據(jù)傳輸?shù)目蛻舳藬?shù)量要求,而且對于出故障的節(jié)點也能迅速定位處理。傳統(tǒng)的使用集線器的星型網(wǎng)絡在邏輯上仍然屬于總線型網(wǎng)絡 (共享介質(zhì)),因此本文在進行sACN舞臺燈光控制網(wǎng)絡設計時,選擇以交換機為中心節(jié)點的星型網(wǎng)絡作為舞臺燈光控制網(wǎng)絡的拓撲結(jié)構(gòu),在進行多客戶端節(jié)點向服務器回復應答信號過程中,采用順序應答機制的軟件控制方法發(fā)送舞臺燈光應答幀,在實現(xiàn)sACN協(xié)議數(shù)據(jù)傳輸?shù)耐瑫r,能通過應答信號的信息來反映工作節(jié)點的狀態(tài)及確認信息,同時,減小數(shù)據(jù)沖突,對sACN協(xié)議的功能進行了擴展,為舞臺燈光控制網(wǎng)絡的未來發(fā)展提供一種思路[9]。

2 舞臺燈光控制網(wǎng)絡沖突避免機制

由于sACN協(xié)議使用不可靠的UDP傳輸機制傳輸燈光數(shù)據(jù),不保證所有的數(shù)據(jù)包都被接收,服務端總是向客戶端不停的發(fā)送燈光數(shù)據(jù)來抑制或消除數(shù)據(jù)包丟失的影響,這樣會使網(wǎng)絡負載加重。本節(jié)首先定義了一種舞臺燈光應答幀格式,當客戶端接收到sACN協(xié)議數(shù)據(jù)后向服務端回復應答幀,告知其收發(fā)狀態(tài)、儀器性能等。當多客戶端都發(fā)送應答幀時,傳統(tǒng)的CSMA/CD機制會導致客戶端等待時間延長,效率降低,本文提出了順序應答機制來避免回復時的數(shù)據(jù)沖突,提高傳輸效率[10]。

2.1 舞臺燈光應答幀設計

當客戶端節(jié)點接收到sACN協(xié)議數(shù)據(jù)后,如果向服務器回復反饋信息,首先就需要確定服務器的位置,而在回復信息中又需要包含自己的位置信息和一些狀態(tài)信息——如本機是否運行正常、是否接收到服務器的sACN數(shù)據(jù)等。

在以太網(wǎng)局域網(wǎng)中,服務器和每一個客戶端都會分配到一個IP地址,在局域網(wǎng)中,每一個設備的IP地址都是不同的,因此在局域網(wǎng)中可以使用其32位IP地址來確定各自的位置。而如果控制規(guī)模擴展到多個局域網(wǎng),服務器收到的IP地址信息就不能確定客戶端是屬于哪一個局域網(wǎng)。在ACN協(xié)議中,每一個燈光設備都有一個唯一的標識符 CID (component identifier)[11], 由 于 sACN 協(xié) 議 使 用ACN整體協(xié)議的一部分,sACN是支持CID使用的。無論是在單局域網(wǎng)內(nèi)還是多局域網(wǎng)內(nèi),CID都可以準確定位到客戶端的位置。如圖3所示,是設計的舞臺燈光應答幀格式。Sequence Number是表示該應答幀的序列號;A(ACK)指示是否收到sACN協(xié)議數(shù)據(jù),1代表收到,0代表沒收到;S(State)表示客戶機的狀態(tài),1代表功能正常,0代表異常;Options為以后的功能做預留;Length表示該應答幀的長度;CID指客戶機的唯一設備標識符。每一個服務端都有一個CID的映射表,記錄了服務端所管理的所有客戶端的信息如CID、狀態(tài)信息。當服務端接收到應答幀時,根據(jù)應答幀中的CID來查詢服務端中的映射表,讀取S狀態(tài)信息來實時修改客戶端狀態(tài);根據(jù)A信息來判斷客戶端收發(fā)sACN燈光數(shù)據(jù)的情況,用以確定是否需要重新發(fā)送燈光數(shù)據(jù)。

圖3 舞臺燈光應答幀格式

2.2 CSMA/CD機制

CSMA/CD機制是以太網(wǎng)中使用最多的沖突避免機制之一。以太網(wǎng)局域網(wǎng)中的節(jié)點是通過廣播信道進行互聯(lián)的,因此當一個節(jié)點發(fā)送一個以太網(wǎng)幀時,局域網(wǎng)上的所有節(jié)點都會接收到該幀。傳統(tǒng)的共享介質(zhì)以太網(wǎng)中,節(jié)點使用CSMA/CD機制來競爭信道的使用權(quán)。CSMA/CD的工作原理是:在發(fā)送數(shù)據(jù)前,先監(jiān)聽信道是否空閑,如果空閑就立即發(fā)送數(shù)據(jù);在發(fā)送數(shù)據(jù)時,繼續(xù)監(jiān)聽信道,如果監(jiān)聽到信道沖突,就立即停止發(fā)送數(shù)據(jù),等待一段隨機時間后再重新嘗試發(fā)送[12]。

CSMA/CD的發(fā)送控制流程如圖4所示。常用的退避算法是截斷的二進制指數(shù)退避算法[13],即當一個節(jié)點發(fā)現(xiàn)線路忙時,要等待一個延時時間M,然后再進行監(jiān)聽工作。延時時間M由以下算法決定:M=0到2k-1之間的一個隨機數(shù)乘以512比特時間 (例如對于10Mbps以太網(wǎng),1比特時間為0.1μs),k為沖突 (碰撞)的次數(shù),M的最大值為1023,即當k=10及以后M始終是0到1023之間的一個隨機值與512比特時間的乘積,當k增加到16時,就發(fā)出錯誤信息。

圖4 CSMA/CD發(fā)送控制流程

若少量客戶端進行競爭信道待發(fā)送舞臺燈光應答幀時,CSMA/CD機制有其靈活的優(yōu)點。但是在舞臺燈光領(lǐng)域,控制的客戶端規(guī)模巨大,在此情形下,若依然使用CSMA/CD機制去競爭信道,必然會由于網(wǎng)絡負載加重導致回復時節(jié)點沖突增多,延時增加,效率下降。若CSMA/CD在沖突處理中使用的二進制指數(shù)退避算法會導致某一節(jié)點退避次數(shù)過多造成節(jié)點發(fā)送延時較大甚至發(fā)送失敗。

2.3 順序應答機制

本文提出了這樣一種順序應答機制來解決網(wǎng)絡高負載下的沖突處理問題。本文設計舞臺燈光控制網(wǎng)絡結(jié)構(gòu)是單服務器多客戶端。順序應答機制是一種軟件沖突避免方法,其原理是:對N個客戶端節(jié)點進行排序,即第1、2、3……N個客戶端節(jié)點,在sACN燈光網(wǎng)絡中,當服務器向客戶端發(fā)送sACN數(shù)據(jù)幀時,客戶端被動的使用條件觸發(fā)機制,即在固定時間τ內(nèi)收到sACN數(shù)據(jù)后才會啟動順序應答的服務過程,若超出τ表示沒有收到sACN數(shù)據(jù)包同時也會啟動順序應答的服務過程,此時應答幀中回復沒有收到數(shù)據(jù)的信息,根據(jù)其排序位置來確定發(fā)送回復幀的延時間隔,單位延時時間為舞臺燈光應答幀從客戶端到服務端的傳輸時間,可適當延長,編號為1的客戶端等待1個單位延時T后發(fā)送應答幀,編號為2的客戶端等待2個單位延時T后發(fā)送,以此類推。這樣N個客戶端經(jīng)過N×T的總延時后都向服務器回復了應答信息。

sACN燈光控制網(wǎng)絡的順序應答機制流程圖如圖5所示。

圖5 順序應答機制流程

3 仿真實驗

本文使用OPNET在星型網(wǎng)絡結(jié)構(gòu),分別對CSMA/CD機制和順序應答機制進行了仿真實驗,通過仿真結(jié)果說明其在不同負載下的沖突程度和平均延遲時間[14]。共享介質(zhì)以太網(wǎng)采用CSMA/CD機制,交換式以太網(wǎng)采用順序應答機制,對不同負載下的平均延時和中心節(jié)點流通量進行仿真實驗,分析比較這兩種機制的性能[15]。

3.1 仿真模型與參數(shù)設置

本文創(chuàng)建了4個星型網(wǎng)絡,如圖6所示,分別是:使用集線器連接的30個節(jié)點網(wǎng)絡1命名為net_hub_30,位于圖中右上,node_267為集線器,hub_30為服務器,其他節(jié)點為客戶端節(jié)點;使用交換機連接的30個節(jié)點網(wǎng)絡2命名為net_switch_30,位于圖中右下,node_236為交換機,switch_30為服務器,其他節(jié)點為客戶端節(jié)點;使用集線器連接的100個節(jié)點網(wǎng)絡3命名為net_hub_100,位于圖中左上,node_100為集線器,hub_100為服務器,其他節(jié)點為客戶端節(jié)點;使用交換機連接的100個節(jié)點網(wǎng)絡4命名為net_switch_100,位于圖中左下,node_202為交換機,switch_100為服務器,其他節(jié)點為客戶端節(jié)點。

使用集線器的星型網(wǎng)絡 (net_hub_30和網(wǎng)絡net_hub_100)實際上就是共享網(wǎng)絡帶寬,邏輯上屬于總線型網(wǎng)絡,機制是CSMA/CD;而使用交換機的星型網(wǎng)絡 (網(wǎng)絡net_switch_30和網(wǎng)絡net_switch_100)是交換式以太網(wǎng)。

仿真中采集的統(tǒng)計量為:服務器的平均延時 (delay)、CSMA/CD機制的數(shù)據(jù)平均碰撞次數(shù) (collision Count)、集線器和交換機的轉(zhuǎn)發(fā)流量 (traffic forwarded)。離散仿真時間為30分鐘。

圖6 仿真網(wǎng)絡模型

3.2 仿真結(jié)果分析

(1)數(shù)據(jù)傳輸平均碰撞次數(shù)

CSMA/CD機制下不同負載時的數(shù)據(jù)傳輸平均碰撞次數(shù)比較如圖7所示。從圖中可以看出,客戶端節(jié)點數(shù)為100的負載下比客戶端節(jié)點為30的負載下的數(shù)據(jù)碰撞次數(shù)高。說明CSMA/CD機制在網(wǎng)絡負載大時,數(shù)據(jù)傳輸沖突大,網(wǎng)絡性能低。

圖7 不同負載下CSMA/CD數(shù)據(jù)傳輸沖突次數(shù)比較

(2)服務器平均延時

圖8所示為共享介質(zhì)以太網(wǎng)和交換式以太網(wǎng)的服務器平均延時比較。

從圖8中可以看出,共享介質(zhì)以太網(wǎng)的服務器平均延時要高于交換式以太網(wǎng)。因此,在舞臺燈光控制領(lǐng)域,選擇服務器延時更小的交換式以太網(wǎng)更容易達到舞臺燈光實時控制的要求,并且易于實現(xiàn)功能擴展。

圖8 共享介質(zhì)以太網(wǎng)和交換式以太網(wǎng)服務器平均延時

(3)中心節(jié)點流通量

圖9所示為共享介質(zhì)以太網(wǎng)的中心節(jié)點集線器與交換式以太網(wǎng)的中心節(jié)點交換機的數(shù)據(jù)流通量的比較。從圖9中可以看出,交換機的數(shù)據(jù)轉(zhuǎn)發(fā)量比集線器大,雖然交換機的工作量相比集線器稍大,但是它的工作量使得交換式以太網(wǎng)的服務器的延時降低,從舞臺燈光控制角度來說,服務器的延時要求優(yōu)先。

圖9 共享介質(zhì)以太網(wǎng)和交換式以太網(wǎng)中心節(jié)點流通量

4 結(jié)束語

本文設計了一種基于sACN協(xié)議的舞臺燈光控制網(wǎng)絡,對sACN協(xié)議的功能進行了拓展,為了提高數(shù)據(jù)傳輸?shù)目煽啃裕瑴p小網(wǎng)絡負載,設計了舞臺燈光應答幀,為了避免回復應答數(shù)據(jù)沖突,提出了順序應答機制沖突避免方法,該方法是以交換機為中心節(jié)點的交換式以太網(wǎng)進行sACN協(xié)議舞臺燈光控制。仿真實驗證明,選擇交換式以太網(wǎng)和順序應答機制進行sACN舞臺燈光控制比CSMA/CD機制的沖突數(shù)量少,延遲時間短,流量高。本文的提出方法將有助于未來的智能燈光控制的研究和發(fā)展。

[1]DMX512-A data transmission protocol for stage light controlling[S].Ministry of Culture of the People’s Republic of China,2008 (in Chinese).[WH/T 32-2008.DMX512-A燈光控制數(shù)據(jù)傳輸協(xié)議 [S].中華人民共和國文化部,2008.]

[2]JU Jie,SUN Ziqiang.RS485based intelligent light control system [C].Shanghai:The 7th Conference on Industrial Instrument and Automation,2006 (in Chinese). [鞠潔,孫自強.基于RS485總線的只能燈光控制系統(tǒng) [C].上海:第七屆工業(yè)儀表與自動化學術(shù)會議,2006.]

[3]LI Zhenfeng,LI Haixia.Design of intelligent lighting controller based on ARM [J].Low Voltage Apparatus,2007 (2):28-30(in Chinese).[李振峰,李海峽.基于ARM的智能燈光控制器設計 [J].低壓電器,2007 (2):28-30.]

[4]JIANG Wei,JIANG Yujian,REN Hui.Analysis and prospect of control system for stage lighting [C].Yantai:CISP,2010:3923-3929.

[5] [Arch]entertainment technology architecture for control networks,E1.17“ACN”architecture [EB/OL].[2005-10-14].http://www.esta.org/tsp/.

[6] ANSI BSR E1.31-2009.Entertainment technology-lightweight streaming protocol for transport of DMX512using ACN [S].Entertainment Services and Technology Association,2009.

[7]SHEN Qing,GUI Weihua,YANG Tiejun.Real-time control performance analysis based on industrial ethernet [J].Computer Engineering,2007,33 (1):233-235 (in Chinese).[沈青,桂衛(wèi)華,楊鐵軍.基于工業(yè)以太網(wǎng)的實時控制性能分析[J].計算機工程,2007,33 (1):233-235.]

[8]DANG Anxi,PEI Shaojing,SHANG Yaodong,et al.Simulation and performance analysis of Ethernet delay [J].Computer Engineering and Applications,2009,45 (2):119-121 (in Chinese).[黨安喜,裴少婧,尚耀東,等.以太網(wǎng)時延仿真與性能分析[J].計算機工程與應用,2009,45 (2):119-121.]

[9]PENG Jie,YING Qijia.Analysis for switched Ethernet applied into industrial real-time communication [J].Low Voltage Apparatus,2007 (1):33-35 (in Chinese). [彭杰,應啟戛.交換式以太網(wǎng)用于工業(yè)實時通信的分析 [J].低壓電器,2007(1):33-35.]

[10]Ricardo Moraes,F(xiàn)rancisco Vasques.Paulo portugal,survey of real-time communication in CSMA-based networks [J].Networks Protocols and Algorithms,2010,2 (1):158-183.

[11]BAI Shilei,REN Hui,JIANG Wei,et al.Research on device identify mechanism in performance light network control system [J].Journal of Communication University of China Science and Technology,2009,16 (2):64-67 (in Chinese).[白石磊,任慧,蔣偉,等.演藝燈光網(wǎng)絡控制系統(tǒng)設備識別機制的研究 [J].中國傳媒大學學報自然科學版,2009,16(2):64-67.]

[12]HU Jianjun.Research of work theory for CSMA/CD protocol[J].Science Technology and Engineering,2008,8 (24):6622-6624 (in Chinese). [胡建軍.以太網(wǎng) CSMA/CD 工作原理 研 究 [J]. 科 學 技 術(shù) 與 工 程,2008,8 (24):6622-6624.]

[13]YU Li,CAO Limin,XIONG Hui.Simulation and analysis of the adaptive binary exponential back off algorithm [J].Journal of Huazhong University of Science and Technology(Natural Science Edition),2007,35 (1):29-31 (in Chinese).[喻莉,曹利敏,熊慧.改進的沖突檢測算法仿真與分析[J].華中科技大學學報 (自然科學版),2007,35 (1):29-31.]

[14]ZHEN Li,LIU Ke.Research of emulation for Ethernet based on OPNET modeler[J].Industrial Control Computer,2008,21 (9):35-36 (in Chinese). [甄力,劉克.基于 OPNET Modeler的以太網(wǎng)性能的仿真研究 [J].工業(yè)控制計算機,2008,21 (9):35-36.]

[15]GONG Lining,XU Yubin,MU Xiaoguang.Study on realtime performance of switched Ethernet using OPNET simulation [J].Industrial Control Computer,2008,21 (4):60-61(in Chinese).[宮麗寧,徐玉斌,牟肖光.基于OPNET的交換式以太網(wǎng)實時性仿真分析 [J].工業(yè)控制計算機,2008,21 (4):60-61.]

主站蜘蛛池模板: 伦精品一区二区三区视频| 99视频精品在线观看| 国产69精品久久| 亚洲福利片无码最新在线播放| 国产一区亚洲一区| 国产91丝袜| 日韩精品久久久久久久电影蜜臀| 日韩在线永久免费播放| 99久久成人国产精品免费| 国产亚洲美日韩AV中文字幕无码成人| 丁香六月激情综合| 日本高清免费不卡视频| 久久精品国产电影| 亚洲第一区精品日韩在线播放| 久久天天躁狠狠躁夜夜躁| 亚洲av无码成人专区| 久久久久人妻一区精品色奶水 | 欧美日韩亚洲国产主播第一区| 久久99热这里只有精品免费看| 亚洲大尺码专区影院| 爆乳熟妇一区二区三区| 亚洲精品国产成人7777| 丝袜高跟美脚国产1区| 亚洲精品国产成人7777| 日本欧美在线观看| 97久久免费视频| 在线播放真实国产乱子伦| 国产自无码视频在线观看| 国产乱人乱偷精品视频a人人澡| 日韩高清欧美| 精品亚洲欧美中文字幕在线看| 无码不卡的中文字幕视频| 夜精品a一区二区三区| 色噜噜综合网| 欧美日本激情| 国产成人精品一区二区不卡| 内射人妻无码色AV天堂| 啪啪永久免费av| 欧美日韩精品综合在线一区| 操美女免费网站| 国产激情无码一区二区APP | 国产精品美女自慰喷水| 午夜久久影院| 日本高清在线看免费观看| 欧美午夜在线观看| 精品视频一区二区三区在线播| 在线免费观看a视频| 国产91小视频| 日韩欧美91| 久久久久免费看成人影片| 91小视频版在线观看www| 亚洲精品大秀视频| 国产欧美日韩专区发布| 韩日无码在线不卡| 国产小视频免费观看| 伊大人香蕉久久网欧美| 日韩第一页在线| 三上悠亚在线精品二区| 69视频国产| 成人蜜桃网| 久青草国产高清在线视频| 小蝌蚪亚洲精品国产| 亚洲综合精品香蕉久久网| 国产亚洲视频免费播放| 亚洲天堂视频网| 欧美激情第一区| 日韩精品毛片人妻AV不卡| 日韩精品一区二区三区视频免费看| 无码高潮喷水专区久久| a级毛片在线免费| 精品国产三级在线观看| 亚洲天堂日韩在线| 色婷婷狠狠干| 色欲综合久久中文字幕网| 亚欧成人无码AV在线播放| 久久福利网| 色妞www精品视频一级下载| 成年人视频一区二区| 亚洲二三区| a毛片免费在线观看| 欧美日韩亚洲国产主播第一区| 婷婷色一二三区波多野衣|