專利名稱：用ip協(xié)議進(jìn)行串行總線數(shù)據(jù)傳輸?shù)姆椒捌涫褂玫难b置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及應(yīng)用網(wǎng)際網(wǎng)絡(luò)協(xié)議IP進(jìn)行串行總線數(shù)據(jù)通訊的領(lǐng)域，特別是涉及應(yīng)用網(wǎng)際網(wǎng)絡(luò)協(xié)議通過串行總線進(jìn)行實時流傳輸?shù)念I(lǐng)域。
背景技術(shù)：
目前存在許多通過互聯(lián)網(wǎng)進(jìn)行視頻流傳輸?shù)母邏嚎s視頻編碼技術(shù)。這些技術(shù)包括MPEG2或MPEG4視頻/音頻編碼技術(shù)。其它編碼技術(shù)還有H.263、H.264、DIVX或者Windows Media 9等編碼技術(shù)。這些編碼技術(shù)可以將640×480像素8位3基色的標(biāo)準(zhǔn)視頻質(zhì)量的流以25HZ幀頻＝184Mbit/s的速率壓縮100倍或更多倍，使得在帶有DSL調(diào)制解調(diào)器的模擬電話線(數(shù)字用戶線路)上傳輸視頻流成為可能。
在視頻鏈的另一端，即視頻產(chǎn)品的一端，即使是使用專有的冗余簡化方法，大多數(shù)視頻壓縮技術(shù)還是不能令人滿意。因此為通過總線協(xié)議進(jìn)行數(shù)據(jù)通信必須支持的更高的數(shù)據(jù)速率。
在專業(yè)視頻產(chǎn)品領(lǐng)域有一個稱為HDSDI(SMPTE 292M)總線標(biāo)準(zhǔn)，其處理速率大約為1.5Gbit/s。將來還會生產(chǎn)出分辨率越來越高的視頻資料，這就需要更高的數(shù)據(jù)速率，如2k的1920×1080像素10位3基色電影膠片以24幀/秒的速度加上音頻和元數(shù)據(jù)(metadata)會產(chǎn)生1.6Gbit/s的數(shù)據(jù)量。另外，分辨率為3840×2160的4k膠片正在開發(fā)。這時該產(chǎn)業(yè)必須具有6Gbit/s的處理速率。
因此，亟需在攝影場建立基于可以提供2Gbit/s以上數(shù)據(jù)傳輸能力的總線技術(shù)的視頻服務(wù)器和接收器網(wǎng)絡(luò)。以太網(wǎng)總線技術(shù)專用于這些高數(shù)據(jù)速率。目前有提供1Gbit/s數(shù)據(jù)速率的以太網(wǎng)變型，例如1000BASE-SX以太網(wǎng)、1000BASE-LX以太網(wǎng)、1000BASE-CX以太網(wǎng)和1000BASE-T以太網(wǎng)。此外，還有一些基于光纖提供10Gbit/s數(shù)據(jù)速率的特殊以太網(wǎng)變型。這些以太網(wǎng)變型有10GBASE-LX4、10GBASE-SR、10GBASE-LR、10GBASE-ER、10GBASE-SW、10GBASE-LW和10GBASE-EW。
在以太網(wǎng)的物理層上進(jìn)行視頻流傳輸將被越來越多地用于專業(yè)視頻制作中。人們非常希望使用已安裝好的上層，諸如有TCP層(傳輸控制協(xié)議層)、UDP層(用戶數(shù)據(jù)報協(xié)議層)、RTP層(實時傳輸協(xié)議層)和IP層(網(wǎng)際網(wǎng)絡(luò)協(xié)議層)進(jìn)行視頻傳輸，因為這些協(xié)議層堆棧/驅(qū)動器和許多不同的操作系統(tǒng)(OS)安裝在一起。其優(yōu)點是許多現(xiàn)成的軟件工具支持TCP/UDP和IP協(xié)議對這些視頻流進(jìn)行提取/顯示或者存儲/記錄。
現(xiàn)有IP層上的視頻流傳輸應(yīng)用大多數(shù)是基于軟件的。執(zhí)行這些應(yīng)用程序的處理器必須有很高的性能才能實現(xiàn)實時流傳輸。隨著以太網(wǎng)物理層速度級的增加(1000BASET，10Gbit以太網(wǎng)(10GbE))，處理器處理IP包的中斷反應(yīng)時間則需要更多。而現(xiàn)有的處理器不能提供處理10GbE上的IP包所需要的性能。如果考慮下一個上層協(xié)議層(特別是TCP層)，處理器便不具有足夠的性能。

發(fā)明內(nèi)容
為了解決上述問題，本發(fā)明總的概念是提供一種應(yīng)用網(wǎng)際網(wǎng)絡(luò)協(xié)議通過串行總線進(jìn)行數(shù)據(jù)傳輸?shù)姆椒?，將嵌入式軟?硬件結(jié)構(gòu)的TCP/UDP/RTP和IP協(xié)議層分開，在UDP/RTP層上而不在TCP層上進(jìn)行實時流傳輸。在該方法中有時間要求的RTP/UDP/IP協(xié)議完全由硬件支持，而無時間要求的TCP/(UDP)/IP層由嵌入式微處理器上的軟件來實施。本發(fā)明還涉及在由文件系統(tǒng)過程調(diào)用完成實時流傳輸而不是由RTP完成的情況下將協(xié)議層分開的構(gòu)想。
對于在根據(jù)本發(fā)明的方法中使用的裝置，該裝置較佳的是包括處理必需實時傳輸?shù)臄?shù)據(jù)包的硬件裝置，和處理不必實時傳輸?shù)臄?shù)據(jù)包的軟件裝置；以及用于將必需實時傳輸?shù)臄?shù)據(jù)包傳送給硬件裝置并將不必實時傳輸?shù)臄?shù)據(jù)包傳送給軟件裝置的與分用器連接的過濾裝置。
在各從屬權(quán)利要求中會顯見本發(fā)明進(jìn)一步的較佳實施例。
應(yīng)用網(wǎng)絡(luò)技術(shù)其獨到的優(yōu)點是過濾算法所作的以下三個判定1、有些IP數(shù)據(jù)包要進(jìn)行必需實時的處理；2、有些IP數(shù)據(jù)包要進(jìn)行不必實時的處理；3、有些IP數(shù)據(jù)包要加以阻止不進(jìn)行處理。
分析TCP/UDP/IP包頭可以得出過濾裝置的判定條件。該判定取決于下列條件1、傳入的IP數(shù)據(jù)包的IP源地址；2、傳入的IP數(shù)據(jù)包的IP目的地址；3、傳入的IP數(shù)據(jù)包的“協(xié)議”字段的入口；4、傳入的TCP/UDP數(shù)據(jù)包的源端口號；5、傳入的TCP/UDP數(shù)據(jù)包的目的端口號；6、傳入的TCP/UDP數(shù)據(jù)包的遠(yuǎn)程過程調(diào)用功能(程序編號和過程編號)。
通過上述的方式可以使用一個分用器(demultiplexer)根據(jù)過濾判定將數(shù)據(jù)包傳送給正確的處理階段。
概括而論，過濾器判定1)和2)用于阻止對非預(yù)見性傳入的數(shù)據(jù)包的處理，或者通過軟件以簡單的方式，如確認(rèn)“忙碌”來確認(rèn)這些數(shù)據(jù)包不需要實時。上述處理是根據(jù)數(shù)據(jù)包頭中唯一的IP源地址和IP目的地址完成的。
本發(fā)明的一個實施例是用網(wǎng)絡(luò)層進(jìn)行流傳輸。此處RTP(實時傳輸協(xié)議)和RTSP(實時流傳輸協(xié)議)與UDP/IP一起使用。此處數(shù)據(jù)流用RTSP以不必實時的方式進(jìn)行控制，且數(shù)據(jù)包用RTP以必需實時的方式傳輸。UDP/IP層和RTP層必須使用硬件進(jìn)行加速，RTSP可以由軟件處理支持。要達(dá)到上述目的，還需要通過數(shù)據(jù)包在“協(xié)議”字段中的唯一入口、TCP/UDP包的源端口號、TCP/UDP包的目的端口號，利用過濾器判定3)、4)和5)來確定要由硬件進(jìn)行實時處理的數(shù)據(jù)包。所有其他的數(shù)據(jù)包為不必實時傳輸，可以由軟件進(jìn)行處理。
在本發(fā)明的實施例中，使用一個文件系統(tǒng)控制網(wǎng)絡(luò)中的數(shù)據(jù)訪問，所述文件系統(tǒng)具有許多為執(zhí)行不同任務(wù)而實施的過程。這種情況下，較佳的是網(wǎng)絡(luò)工作站包括一個過程過濾器，將必需實時的過程調(diào)用和不必實時的過程調(diào)用分開，將過程調(diào)用分別傳送給硬件裝置或軟件裝置。
為了達(dá)到上述目的本發(fā)明還利用過濾器判定6)根據(jù)必需實時傳輸?shù)臄?shù)據(jù)包的“READ”和“WRITE”過程來確定這些數(shù)據(jù)包，并通過硬件進(jìn)行處理。根據(jù)過程如“creat_file”，所有其他數(shù)據(jù)包可以用軟件以不要求實時的方式進(jìn)行處理。
與現(xiàn)有已知的依賴軟件的解決方法相比較，通過將必需實時的過程和不必實時的過程區(qū)分開，本發(fā)明的實施例可以確保訪問(例如，訪問存儲設(shè)備)所需的數(shù)據(jù)吞吐率。
以本發(fā)明必需實時的流入或流出存儲設(shè)備(如經(jīng)由網(wǎng)絡(luò))的流傳輸，能通過硬件實施的數(shù)據(jù)路徑加速后以2Gbit/s或更高的吞吐速度工作。
實施現(xiàn)有的網(wǎng)絡(luò)文件系統(tǒng)NFS使本發(fā)明尤其有用。


以下參考附圖詳細(xì)說明本發(fā)明的具體實施例圖1為連接在實時存儲設(shè)備上的視頻攝像機；圖2為OSI/ISO數(shù)據(jù)通訊參考模型的不同的層；
圖3a為包括IP頭、UDP頭和RTP頭的以太數(shù)據(jù)包的包格式；圖3b為包括IP頭、UDP頭和RPC頭的以太數(shù)據(jù)包的包格式；圖4為根據(jù)本發(fā)明的設(shè)備的軟件/硬件方塊圖；圖5為根據(jù)本發(fā)明的10G以太網(wǎng)實時高速流傳輸接口的硬件/軟件實施圖；圖6為根據(jù)RPC協(xié)議的過程過濾器結(jié)構(gòu)。
具體實施例方式
圖1中參號10表示專業(yè)視頻攝像機。該攝像機經(jīng)由以太網(wǎng)總線11與存儲設(shè)備12連接。由于未被壓縮的視頻流應(yīng)當(dāng)經(jīng)由總線連接傳輸，所以應(yīng)使用1000BASE-xy或10GBASE-xy中的一個以太網(wǎng)變型。這些以太網(wǎng)變型包括基于光纖或者銅線的總線技術(shù)。上述存儲設(shè)備能夠以每秒2Gbit或更高的速率記錄音頻/視頻數(shù)據(jù)。
圖2所示為周知的OSI/ISO數(shù)據(jù)通訊參考模型。在該例中標(biāo)記了不同的層使用了哪項具體技術(shù)。物理層PHL為以太物理層。數(shù)據(jù)鏈路層為以太MAC層。網(wǎng)際網(wǎng)絡(luò)協(xié)議IP用于實施網(wǎng)絡(luò)層NL。在傳輸層上實施的是UDP/TCP協(xié)議。在該例子中高層會話層SL和表示層PRL未具體說明。應(yīng)用層AL由RTP、RTSP和網(wǎng)絡(luò)文件系統(tǒng)(NFS)的遠(yuǎn)程過程調(diào)用(RPC)表示。
圖3a所示為傳輸部分視頻流的以太包格式。該圖中最高一層描述的是包括視頻數(shù)據(jù)的凈有效載荷數(shù)據(jù)。第二高層表示的是最高層的有效載荷數(shù)據(jù)加上一個RTP頭。第三層表示的是有效載荷數(shù)據(jù)、RTP頭加上RTP頭前的UDP頭。第二層表示的是第三層中的包的擴展，在上述UDP頭前增加了一個IP頭。圖3的底層表示的是完整的以太數(shù)據(jù)包，具有在以太包的最前端的以太頭，IP頭、UDP頭、RTP頭以及數(shù)據(jù)字段中的有效載荷數(shù)據(jù)。
圖3b所示為以NFS的RPC調(diào)用替換RTP層的實施例中相應(yīng)的以太包格式。
圖4所示為根據(jù)本發(fā)明的裝置的軟件和硬件結(jié)構(gòu)方塊圖。所有必需實時的和不必實時的以太數(shù)據(jù)包是通過例如10Gbit以太介質(zhì)20到達(dá)所述裝置。參號21表示以太物理層。包在以太物理層經(jīng)硬件實施之后進(jìn)入以太MAC硬件層中。在MAC硬件層完成上述裝置的MAC識別號過濾。在以太MAC硬件層22之上設(shè)置有多個先入先出(FIFO)存儲器23，以解除所述設(shè)備與以太總線20在時間上的耦合。接收機RX-DMA 24和發(fā)送機TX-DMA 33分別向上層協(xié)議層讀取或填充FIFO存儲器23。
單元25為接收路徑上的IP頭和上層頭過濾器以及數(shù)據(jù)包分用器，以及傳送路徑上的數(shù)據(jù)包復(fù)用器。在此，單元25對特定端口具有預(yù)定的特定源/目的IP地址ID＝xy的必需實時傳輸?shù)臄?shù)據(jù)包和用特定的遠(yuǎn)程過程調(diào)用(RPC)聯(lián)網(wǎng)的文件系統(tǒng)進(jìn)行過濾。在包頭中可以找到進(jìn)行過濾所需的全部信息。因此，所述單元25需要對包中不同的包頭進(jìn)行評估。IP ID出現(xiàn)在圖3所示的IP頭，UDP端口則可以在圖3所示的UDP頭中找到。所識別出的必需實時的UDP包傳遞給基于硬件的IP解碼單元26。下一個處理階段為基于硬件的UDP處理單元27。在UDP層之上為應(yīng)用層30。應(yīng)用層的一部分以專用的硬件裝置實施，該硬件裝置為RTP協(xié)議的硬件。在由NFS遠(yuǎn)程過程調(diào)用產(chǎn)生實時流傳輸?shù)那闆r下，硬件28支持RPC格式。在這種情況下過濾單元25對UDP包中的程序號和過程號很敏感。
單元25對具有相應(yīng)源/目的IP標(biāo)示符(IDs)(圖5中IP ID＝xy)的TCP或UDP端口無時間要求的包進(jìn)行過濾。所述包暫時存儲在隨機儲存器RAM 32中等待嵌入式處理器31的處理。此處用軟件實施TCP/(UDP)/IP協(xié)議層。處理時間比在前述必需實時傳輸?shù)陌臄?shù)據(jù)路徑上慢很多。如果需要，這些數(shù)據(jù)包處理完之后可以在應(yīng)用包復(fù)用器(圖中未示)中與對有時間要求的包流進(jìn)行復(fù)用并提供給應(yīng)用層30。最后由目標(biāo)應(yīng)用程序完成迅速到達(dá)的必需實時傳輸?shù)臄?shù)據(jù)流和不必實時傳輸?shù)臄?shù)據(jù)流的合并。
接下來描述圖4所示另一個方向(即，從設(shè)備發(fā)送數(shù)據(jù)的方向)的處理路徑。如果連接的設(shè)備如播放設(shè)備(圖中未示)通過UDP向目的設(shè)備的專有源IP ID請求必需實時傳輸?shù)臄?shù)據(jù)，嵌入式處理器31向應(yīng)用層30發(fā)送所需數(shù)據(jù)的請求。該數(shù)據(jù)由應(yīng)用層30提供給應(yīng)用包分用器(圖中未示)。該應(yīng)用包復(fù)用器單元直接將數(shù)據(jù)傳送給硬件RTP/RPC單元28、UDP單元27和IP單元26。這些單元分別根據(jù)RTP/RPC、UDP和IP包標(biāo)準(zhǔn)格式化數(shù)據(jù)。然后將所述包提供給包復(fù)用器25接著把復(fù)用后的數(shù)據(jù)包流傳送給硬件TX-DMA單元33。接下來的處理單元為FIFO存儲器23、以太硬件MAC層22、以太物理層21和最后的以太纜線20。
接下來描述具有相同方向但是不必實時傳輸?shù)臄?shù)據(jù)包的處理路徑。如果連接的設(shè)備(例如，Windows/Linux個人電腦)通過FTP、TCP向主設(shè)備請求數(shù)據(jù)包，如上所述，所述FTP/TCP數(shù)據(jù)包請求由嵌入式處理器31接收。所述嵌入式處理器解讀FTP命令并向應(yīng)用層30請求所需的數(shù)據(jù)。數(shù)據(jù)由應(yīng)用層30提供給應(yīng)用包分用器。應(yīng)用包分用器單元將數(shù)據(jù)寫入DRAM 32。嵌入式處理器31由數(shù)據(jù)建立TCP/IP包，并請求頭過濾器和數(shù)據(jù)包復(fù)用單元25將數(shù)據(jù)包發(fā)送給TX-DMA單元33。接下來的處理單元為FIFO存儲器23、以太MAC層硬件單元22、以太物理層21、最后是以太纜線20。
圖5所示為本發(fā)明實施例的更為詳細(xì)的方塊圖。與圖4中相同的部件使用相同的參號。這些部件不再進(jìn)行解釋。
下面分別介紹接收路徑和發(fā)送路徑。在接收路徑，迅速到達(dá)的數(shù)據(jù)包收集在FIFO存儲單元23的FIFO存儲器40中用于時間解耦合。不同的硬件模塊設(shè)有配置塊42，在所述FIFO存儲器塊中便設(shè)有該配置塊。根據(jù)上述的過濾算法在過濾塊25的包頭解析塊43中對RX數(shù)據(jù)包進(jìn)行處理。必需實時傳輸?shù)陌苯犹峁┙o硬件塊中的TX引擎63用于實時協(xié)議堆棧。不必實時傳輸?shù)臄?shù)據(jù)包寫入將系統(tǒng)時鐘與DRAM時鐘解耦合的FIFO 44中。從FIFO 44出來后的數(shù)據(jù)包通過四通道DRAM控制器48提供給DRAM 32。在這里，這些數(shù)據(jù)包由可基于處理器核PPC405的微控制器31進(jìn)行處理。所述處理器由其接口端55與四通道DRAM控制器48連接。所述TX引擎63將必需實時傳輸?shù)臄?shù)據(jù)包提供給硬件處理模塊MAC用戶65，IP 26和UDP 27進(jìn)行實時協(xié)議堆棧。在這些模塊中根據(jù)相應(yīng)的標(biāo)準(zhǔn)完成數(shù)據(jù)包的評估。應(yīng)用程序接口66將必需實時傳輸?shù)臄?shù)據(jù)包提供給應(yīng)用程序模塊29，在其特定的實時硬件模塊28中完成RTP或RPC處理。由接收到的以太數(shù)據(jù)包發(fā)布的所有不必實時的主題(topic)在負(fù)責(zé)處理DRAM24中不必實時傳輸?shù)囊蕴珨?shù)據(jù)包的微控制器31和應(yīng)用微處理器核67之間通過應(yīng)用接口61進(jìn)行處理。
為了進(jìn)行傳輸，所述應(yīng)用程序29的微處理器核67向微控制器31發(fā)布一個發(fā)送請求，該微控制器31為傳輸目的對所有必要的模塊進(jìn)行配置。之后，應(yīng)用程序29將必需實時傳輸?shù)臄?shù)據(jù)包通過RTP/RPC模塊28和應(yīng)用程序接口61提供給UDP27、IP26和MAC客戶65硬件模塊，分別“實時”(on-the-fly)根據(jù)各標(biāo)準(zhǔn)實時格式化數(shù)據(jù)包。RX引擎64數(shù)據(jù)包經(jīng)由FIFO 45提供給定時數(shù)據(jù)路徑復(fù)用器46。在此，必需實時傳輸?shù)臄?shù)據(jù)包與DRAM 32中微控制器31所提供的不必實時傳輸?shù)臄?shù)據(jù)包混合，其中的數(shù)據(jù)包由DRAM控制器48取出并提供給FIFO 47。然后，所有的數(shù)據(jù)包寫入TX-FIFO41中進(jìn)行時間解耦合，并分別經(jīng)由以太MAC 22和以太物理層模塊21發(fā)送給光纖和銅介質(zhì)20。
關(guān)于前述的RPC主題，將參考圖6對本發(fā)明另一實施例進(jìn)行描述。
與圖4的數(shù)據(jù)處理結(jié)構(gòu)類似的是諸如音頻/視頻(AV)系統(tǒng)的實時數(shù)據(jù)處理結(jié)構(gòu)。對于這些領(lǐng)域中的所有應(yīng)用而言，關(guān)鍵的問題是對存儲設(shè)備的快速訪問。雖然個人電腦領(lǐng)域的應(yīng)用在快速訪問數(shù)據(jù)方面興趣很高，但是存儲設(shè)備方面的數(shù)據(jù)安全(數(shù)據(jù)冗余)也很重要。因此目前在電腦領(lǐng)域?qū)?shù)據(jù)訪問的控制仍不能實時進(jìn)行也不能以軟件實現(xiàn)。
隨著AV實時領(lǐng)域的新應(yīng)用需要支持2Gbit/s的數(shù)據(jù)吞吐率，通過軟件不再可能支持具有智能文件系統(tǒng)(FS)控制的高數(shù)據(jù)吞吐量。
有一個用于管理網(wǎng)絡(luò)文件的數(shù)據(jù)訪問的文件系統(tǒng)，稱為網(wǎng)絡(luò)文件系統(tǒng)NFS(Network File System)。NFS為用在網(wǎng)絡(luò)的RPC層、UDP層和IP層堆棧上層的基于UNIX的偽文件系統(tǒng)，其中NFS為一組遠(yuǎn)程過程調(diào)用RPC。在本發(fā)明的實施例中，核心問題是引入將NFS層的過程分為由軟件支持的任務(wù)和由硬件實施的任務(wù)的機制。
所述軟件部分以“非實時”行為，如GETATTR，CREATE或REMOVE(參見表1)，管理除NFS過程READ和WRITE以外的NFS控制過程。
表一不同版本號的所有NFS過程


圖6所示為圖5的過濾單元25在RPC過濾情況下的結(jié)構(gòu)。過濾單元25包含兩個表，一個用于軟件路徑，一個用于硬件路徑。這兩個表包括需要通過的過程名稱。由NFS版本號指引所述表。NFS層的硬件部分中只有兩個過程通過READ和WRITE(必需實時數(shù)據(jù)流傳輸?shù)倪^程)。其他的過程轉(zhuǎn)發(fā)至NFS層的軟件路徑。
與現(xiàn)有周知的完全依賴于軟件的解決方案相此較，本發(fā)明通過將必需實時的NFS過程和不必實時的過程區(qū)分開，確保了訪問例如存儲設(shè)備所需的(高)數(shù)據(jù)吞吐率。
運用本發(fā)明必需實時傳輸?shù)臄?shù)據(jù)流流入或流出NFS存儲設(shè)備，如通過網(wǎng)絡(luò)，可以由硬件實施的數(shù)據(jù)路徑加速到2Gbit/s或以上的吞吐率。
所述實施例可能有落在權(quán)利要求范圍內(nèi)不同修改。
權(quán)利要求
1.一種應(yīng)用網(wǎng)際網(wǎng)絡(luò)協(xié)議通過串行總線(20)進(jìn)行數(shù)據(jù)傳輸?shù)姆椒?，其中所述?shù)據(jù)傳輸包括必需實時傳輸?shù)臄?shù)據(jù)包和不必實時傳輸?shù)臄?shù)據(jù)包，其特征在于所述必需實時傳輸?shù)臄?shù)據(jù)包的傳送是基于用戶數(shù)據(jù)報協(xié)議UDP和一個實時傳輸協(xié)議RTP或文件系統(tǒng)的過程調(diào)用，所述不必實時傳輸?shù)臄?shù)據(jù)包的傳送是基于傳輸控制協(xié)議TCP和/或用戶數(shù)據(jù)報協(xié)議UDP。
2.根據(jù)權(quán)利要求1的方法中使用的裝置，包括一個串行總線(20)接口，其特征在于該裝置包括用于處理必需實時傳輸?shù)臄?shù)據(jù)包的硬件裝置(26、27、28)，用于處理不必實時傳輸?shù)臄?shù)據(jù)包的軟件裝置，以及將必需實時傳輸?shù)臄?shù)據(jù)包傳送給硬件裝置(26、27、28)并將不必實時傳輸?shù)臄?shù)據(jù)包傳送給軟件裝置的過濾單元(25)。
3.根據(jù)權(quán)利要求2的裝置，其中所述過濾單元(25)包括基于數(shù)據(jù)包的源設(shè)備或目的設(shè)備的IP地址、IP包類型和端口號對數(shù)據(jù)包進(jìn)行過濾的裝置。
4.根據(jù)權(quán)利要求3的裝置，其中所述過濾裝置包括一個過程過濾器，在數(shù)據(jù)包基于用戶數(shù)據(jù)報協(xié)議UDP和文件系統(tǒng)的過程調(diào)用傳送的情況下，基于過程調(diào)用的類型進(jìn)行過濾。
5.根據(jù)權(quán)利要求4的裝置，其中所述過程過濾器(42)包含一個傳送給硬件裝置(43)的過程調(diào)用表和一個傳送給軟件裝置(41)的過程調(diào)用表。
6.根據(jù)權(quán)利要求4的裝置，其中所述文件系統(tǒng)為網(wǎng)絡(luò)文件系統(tǒng)NFS并且所述過程調(diào)用為遠(yuǎn)程過程調(diào)用。
7.根據(jù)權(quán)利要求5或6的裝置，其中只有NFS_READ和NFS_WRITE過程調(diào)用是傳送給硬件裝置(26、27、28)的遠(yuǎn)程過程調(diào)用。
全文摘要
應(yīng)用網(wǎng)際網(wǎng)絡(luò)協(xié)議IP的串行總線(20)實時流傳輸越來越重要。隨著新的總線技術(shù)如10Gbit以太網(wǎng)的應(yīng)用，即使是高清晰電影質(zhì)量和不壓縮格式的流傳輸也成為可能。然而，在這種情況下用軟件方法進(jìn)行的數(shù)據(jù)訪問管理便至關(guān)重要，或者即使是在軟件運行時使用高性能的微控制器也會只是因為性能的原因而不能實現(xiàn)。本發(fā)明提出一種網(wǎng)絡(luò)中的裝置，用于實施硬件裝置(26、27、28)來處理必需實時傳輸?shù)臄?shù)據(jù)包，并實施軟件裝置來處理不必實時傳輸?shù)臄?shù)據(jù)包，以及用于分析包頭和將必需實時傳輸?shù)臄?shù)據(jù)包傳送給硬件裝置(26、27、28)并將不必實時傳輸?shù)臄?shù)據(jù)包傳送給軟件裝置的過濾算法和分用器(25)。
文檔編號H04L29/06GK1822592SQ20061000758
公開日2006年8月23日 申請日期2006年2月17日 優(yōu)先權(quán)日2005年2月18日
發(fā)明者布魯恩·托馬斯, 凱利爾·拉爾夫, 多羅·卡 申請人:湯姆遜許可公司