本發(fā)明計算機(jī)領(lǐng)域，尤其涉及一種基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法和系統(tǒng)。

背景技術(shù)：

目前，對經(jīng)過k2路由器的http用戶行為數(shù)據(jù)包上報的上行文件的處理過程包括解壓、解密和解析三個過程，其中上行文件的保存格式如圖1所示，舊版本數(shù)據(jù)處理架構(gòu)如圖2所示，這三個過程采用的單節(jié)點多線程技術(shù)，每一個線程負(fù)責(zé)一個上行文件的處理方式是循環(huán)順序處理，而每個上行文件中有上千萬個數(shù)據(jù)包，每一個數(shù)據(jù)包的處理方式相同，每當(dāng)一個線程完成一個上行文件的解壓解密操作之后，對該上行文件中對每個數(shù)據(jù)包(packet)的處理采用的是順序處理，解析效率極低。

為了解決上述技術(shù)問題，人們進(jìn)行了長期的探索，例如中國專利公開了一種網(wǎng)絡(luò)數(shù)據(jù)包負(fù)載均衡和預(yù)解析方法[申請?zhí)枺篶n201510535316.5]，建立于一臺眾核服務(wù)器上，具體包括1個交換芯片和2個多核可編程智能包引擎，簡稱mpipe；每個mpipe分別對應(yīng)1個具有36核的tileracpu；其特征在于，具體包括以下步驟：步驟一、在眾核服務(wù)器下配置交換芯片；交換芯片的物理端口平均分成兩組，每一組分別對應(yīng)1個mpipe，從每個mpipe對應(yīng)的物理端口中任選一個組成邏輯端口，通過trunk命令進(jìn)行邏輯端口的綁定；步驟二、輸入的數(shù)據(jù)包經(jīng)過交換芯片的外接接口xgbe進(jìn)入后，平均分到2個mpipe；數(shù)據(jù)包經(jīng)過交換芯片的邏輯端口后，如果數(shù)據(jù)包的目的ip和源ip相同，將數(shù)據(jù)包分發(fā)到同一個物理端口，進(jìn)而轉(zhuǎn)發(fā)到物理端口對應(yīng)的mpipe；步驟三、每個mpipe將數(shù)據(jù)包轉(zhuǎn)發(fā)到對應(yīng)的tileracpu上，并進(jìn)行數(shù)據(jù)包預(yù)解析；步驟四、在每個tileracpu上調(diào)用pthread_create庫函數(shù)創(chuàng)建36個數(shù)據(jù)包處理線程；步驟五、為每個數(shù)據(jù)包處理線程分別綁定一個tileracpu核；步驟六、將數(shù)據(jù)包的預(yù)解析結(jié)果分發(fā)到對應(yīng)的數(shù)據(jù)包處理線程；配置邏輯端口的hash算法，針對具有相同目的ip和源ip的數(shù)據(jù)包，計算數(shù)據(jù)包的id值，根據(jù)id值判斷，將相同id值的數(shù)據(jù)包傳輸給綁定的同一個數(shù)據(jù)包處理線程；步驟七、36個處理線程分別通過調(diào)用庫函數(shù)gxio_mpipe_iqueue_try_peek接收數(shù)據(jù)包并且得到預(yù)解析結(jié)果，保存源ip和目的ip。

再如，一種多線程分析的均衡分流方法[申請?zhí)枺篶n201610761812.7]，具體方法為，對于n個線程，從線程0-(n-1)，依次為每個線程分配一個線程序列值threadindexid；所述n為大于1的整數(shù)；所述線程每個線程用于分析分配得到的數(shù)據(jù)包；創(chuàng)建一個數(shù)組空間，該數(shù)組空間包括n個數(shù)組，一一對應(yīng)n個線程；每個線程所對應(yīng)的那個數(shù)組用于存放該線程當(dāng)前等待處理的數(shù)據(jù)個數(shù)；當(dāng)向一個線程投遞一個數(shù)據(jù)包時，該線程所對應(yīng)的那個數(shù)組中用于存放該線程當(dāng)前等待處理的數(shù)據(jù)個數(shù)值自加；當(dāng)線程分析完一個數(shù)據(jù)包時，數(shù)組中用于存放該線程當(dāng)前等待處理的數(shù)據(jù)個數(shù)值自減；數(shù)據(jù)包采集線程采集到數(shù)據(jù)包，按照tcp/ip協(xié)議的規(guī)范，得到每個數(shù)據(jù)包的四元組信息，進(jìn)而得到每個數(shù)據(jù)包的哈希值；使用得到的哈希值與分析線程個數(shù)求模得到每個數(shù)據(jù)包關(guān)于線程的數(shù)據(jù)包線程序列值threadindex；所述數(shù)據(jù)包線程序列值threadindex指示該數(shù)據(jù)包所應(yīng)該分配到的實際線程，該實際線程的線程序列值threadindexid等于該數(shù)據(jù)包線程序列值threadindex；定義一個用于均勻分流的哈希表，將數(shù)據(jù)包的四元組信息作為哈希表的key值，用于查詢，將該數(shù)據(jù)包的實際分配線程序列值threadindexid作為哈希表的value值寫入；

數(shù)據(jù)包分配的具體方法步驟為：s1、查詢當(dāng)前數(shù)據(jù)包的四元組信息是否在哈希表中，如果是，則找到其在哈希表中對應(yīng)的value值，從而找到該數(shù)據(jù)包實際應(yīng)該對應(yīng)的線程序列值threadindexid，將該數(shù)據(jù)包直接分配給該線程等待處理；如果否，則進(jìn)入下一步；s2查詢當(dāng)前數(shù)據(jù)包的數(shù)據(jù)包線程序列值threadindex，從數(shù)組空間中讀取其所對應(yīng)的待處理的數(shù)據(jù)包個數(shù)是不是最多的一個線程，如果不是則直接分配給線程；如果是，進(jìn)入下一步；s2、檢查該數(shù)據(jù)包是不是會話的第一個數(shù)據(jù)包，如果不是，則將該數(shù)據(jù)包分配給線程；如果是，則將該數(shù)據(jù)包分配到當(dāng)前等待處理的數(shù)據(jù)個數(shù)最少的線程，并將該數(shù)據(jù)包的四元組信息作為key值，實際分配的線程序列值threadindexid作為value值記錄在哈希表中。

上述兩個技術(shù)方案雖然在一定程度上提高了解析的效率，但是第一個方案公開的是數(shù)據(jù)包的預(yù)解析結(jié)果分發(fā)到對應(yīng)的數(shù)據(jù)包處理線程，其技術(shù)方案仍然是采用單線程對網(wǎng)絡(luò)數(shù)據(jù)包進(jìn)行解析；第二個方案雖然解決了數(shù)據(jù)包分配不均勻的問題，但是解析效率增長的幅度不夠大，仍然有待提高。

技術(shù)實現(xiàn)要素：

本發(fā)明的目的是針對上述問題，提供一種能夠提高解析處理速度的基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法；

本發(fā)明的另一目的是針對上述問題，提供一種基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理系統(tǒng)。

為達(dá)到上述目的，本發(fā)明采用了下列技術(shù)方案：

本發(fā)明的基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法，包括以下方法：

s1：從服務(wù)器中獲取用戶行為數(shù)據(jù)的上行文件；

s2：主進(jìn)程生成多個子進(jìn)程，且每個子進(jìn)程生成多個父線程；

s3：每個父線程分別對單個上行文件進(jìn)行解壓和解密處理操作；

s4：每個父線程生成多個子線程，由子線程對上行文件中的數(shù)據(jù)包進(jìn)行解析處理。

通過上述技術(shù)方案，將上行文件經(jīng)過在父線程解壓和解密處理的數(shù)據(jù)包分發(fā)給子線程進(jìn)行解析處理，成倍提高協(xié)議解析速度。

在上述的基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法中，在步驟s4中，子線程對上行文件中的數(shù)據(jù)包進(jìn)行解析的方法包括：

s4-1：在父線程完成一個上行文件的解密與解壓操作后，從該上行文件中獲取一個數(shù)據(jù)包；

s4-2：判斷在s4-1步驟中獲取的數(shù)據(jù)包是否為空數(shù)據(jù)包，若數(shù)據(jù)包為非空數(shù)據(jù)包，則將數(shù)據(jù)包分配給當(dāng)前處于空閑狀態(tài)的子線程；

s4-3：由接收數(shù)據(jù)包的子線程對數(shù)據(jù)包進(jìn)行解析處理。

在上述的基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法中，所述的服務(wù)器中用戶行為數(shù)據(jù)的上行文件為路由器上報的上行文件數(shù)據(jù)。

在上述的基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法中，當(dāng)一個子線程正在對一個數(shù)據(jù)包進(jìn)行解析處理的時候處于忙碌狀態(tài)，不接收新的數(shù)據(jù)包，且當(dāng)一個子線程完成對一個數(shù)據(jù)包的解析處理后恢復(fù)到空閑狀態(tài)，等待接收新的數(shù)據(jù)包。

在上述的基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法中，所述的子線程對數(shù)據(jù)包的解析處理包括對相應(yīng)數(shù)據(jù)包的協(xié)議數(shù)據(jù)字段提取處理。

在上述的基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法中，在步驟s2中，所述的主進(jìn)程生成至少五個子進(jìn)程，每個子進(jìn)程生成至少五十個父線程。

在上述的基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法中，在步驟s4中，每個所述的父線程生成至少五十個子線程。

在上述的基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法中，在步驟s2中，所述的主進(jìn)程根據(jù)上行文件的數(shù)量和/或大小生成相應(yīng)個數(shù)的子進(jìn)程，每個子進(jìn)程根據(jù)相應(yīng)上行文件的數(shù)量和/或大小生成相應(yīng)個數(shù)的父線程。

在上述的基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法中，在步驟s4中，每個所述的父線程根據(jù)相應(yīng)數(shù)據(jù)包的數(shù)量和/或大小生成相應(yīng)個數(shù)的子線程。

一種基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法的基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理系統(tǒng)。

本發(fā)明基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法和系統(tǒng)相較于現(xiàn)有技術(shù)具有以下優(yōu)點：成倍提高協(xié)議數(shù)據(jù)字段的提取，縮短上行文件的處理時間，提高效率。

附圖說明

圖1是上行文件的保存格式；

圖2是現(xiàn)有技術(shù)數(shù)據(jù)處理架構(gòu)圖；

圖3是本發(fā)明數(shù)據(jù)處理架構(gòu)圖；

圖4是本發(fā)明實施例一對上行文件進(jìn)行處理的工作流程圖；

圖5是本發(fā)明實施例一子線程對數(shù)據(jù)包解析過程的流程圖。

具體實施方式

本實施例可應(yīng)用于對經(jīng)過路由器的http用戶行為數(shù)據(jù)包上報的上行文件的處理過程，主要采用多線程并行處理的方式提高上行文件數(shù)據(jù)包的協(xié)議解析速度，解決了現(xiàn)有技術(shù)對上行文件采用順序處理導(dǎo)致的解析效率低等問題

以下是本發(fā)明的優(yōu)選實施例并結(jié)合附圖，對本發(fā)明的技術(shù)方案作進(jìn)一步的描述，但本發(fā)明并不限于這些實施例。

實施例一

如圖3和圖4所示，本發(fā)明的基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法，包括以下方法：

s1：從服務(wù)器中獲取用戶行為數(shù)據(jù)的上行文件；

具體地，服務(wù)器中用戶行為數(shù)據(jù)的上行文件為路由器上報的上行文件數(shù)據(jù)。

s2：在獲取用戶行為數(shù)據(jù)的上行文件之后，啟動主進(jìn)程，由主進(jìn)程生成多個子進(jìn)程，且每個子進(jìn)程生成多個父線程；

s3：每個父線程分別對單個上行文件進(jìn)行解壓和解密處理操作；

s4：每個父線程生成多個子線程，由子線程對上行文件中的數(shù)據(jù)包進(jìn)行解析處理。

且為了滿足解壓、解密、以及解析的需要，保證前述三個過程的效率，主進(jìn)程生成至少五個子進(jìn)程，每個子進(jìn)程生成至少五十個父線程，以及每個父線程生成至少五十個子線程。

且本實施例中，每次在獲取上行文件后，對上行文件進(jìn)行處理的時候，生成固定個數(shù)的子進(jìn)程，以及固定個數(shù)的父線程和固定個數(shù)的子線程，比如，每次在對上行文件的處理過程中，生成五個子進(jìn)程，五個父線程，以及五十個子線程。

下面對在生成五個子進(jìn)程、五個父線程和五十個子線程的情況下進(jìn)行具體說明：

其中主進(jìn)程用于接收上行文件，然后將上行文件分發(fā)給五個子進(jìn)程，子進(jìn)程又將自己接收到的所有上行文件分發(fā)給各自下面的五十個父線程，父線程對上行文件進(jìn)行解壓和解密處理，通常每個上行文件經(jīng)過父線程的解壓和解密處理后生成成千上萬個數(shù)據(jù)包，現(xiàn)有技術(shù)中每一個數(shù)據(jù)包的處理方式相同，每當(dāng)一個線程完成一個上行文件的解壓解密操作之后，對該上行文件中對每個數(shù)據(jù)包(packet)的處理采用的是順序處理，解析效率極低，而本實施例的每個父線程在將上行文件解壓和解密處理后，又將每個上行文件的成千上萬個數(shù)據(jù)包分發(fā)給各自下面的五十個子線程，由五十個子線程對成千上萬個數(shù)據(jù)包進(jìn)行并行處理。

進(jìn)一步地，每個子線程對數(shù)據(jù)包的解析處理包括對相應(yīng)數(shù)據(jù)包的協(xié)議數(shù)據(jù)字段提取處理。

本實施例采用多線程并行處理的方式，提高的協(xié)議解析速度的倍數(shù)等于并行處理的線程數(shù)，而目前上行文件的收集存儲數(shù)量已經(jīng)增長到tb級別，從而縮短上行文件的處理時間所帶來的成效是顯著的。

進(jìn)一步地，如圖5所示，在步驟s4中，子線程對上行文件中的數(shù)據(jù)包進(jìn)行解析的方法包括：

s4-1：在父線程完成一個上行文件的解密與解壓操作后，從該上行文件中獲取一個數(shù)據(jù)包；

對子線程進(jìn)行狀態(tài)監(jiān)控，當(dāng)一個子線程正在對一個數(shù)據(jù)包進(jìn)行解析處理的時候處于忙碌狀態(tài)，不接收新的數(shù)據(jù)包，所以不會將數(shù)據(jù)包分發(fā)給這一類子線程，而當(dāng)一個子線程完成對一個數(shù)據(jù)包的解析處理后恢復(fù)到空閑狀態(tài)，等待接收新的數(shù)據(jù)包，從上行文件獲取的數(shù)據(jù)包便是分發(fā)給這一類處于空閑狀態(tài)的子線程，最大限度地減少數(shù)據(jù)包的排隊時間，只要有空閑的子線程存在，就能夠接受對數(shù)據(jù)包進(jìn)行的解析任務(wù)。

s4-2：判斷在s4-1步驟中獲取的數(shù)據(jù)包是否為空數(shù)據(jù)包，若數(shù)據(jù)包為非空數(shù)據(jù)包，則表明該數(shù)據(jù)包未經(jīng)解析處理，則將數(shù)據(jù)包分配給當(dāng)前處于空閑狀態(tài)的子線程；

s4-3：由接收數(shù)據(jù)包的子線程對數(shù)據(jù)包進(jìn)行解析處理。

相應(yīng)的接收數(shù)據(jù)包的子線程對該數(shù)據(jù)包進(jìn)行包括協(xié)議數(shù)據(jù)字段提取的解析處理，此時，該子線程對外表現(xiàn)為忙碌狀態(tài)，不再接收數(shù)據(jù)包的任務(wù)分發(fā)；

當(dāng)對當(dāng)前的數(shù)據(jù)包解析完成后，該子線程即回到空閑狀態(tài)以等待接收新的數(shù)據(jù)包的解析任務(wù)；

而當(dāng)數(shù)據(jù)包未空數(shù)據(jù)包的時候表明該數(shù)據(jù)包以經(jīng)過解析處理或不需要進(jìn)行解析處理，則直接結(jié)束對該數(shù)據(jù)包的解析處理過程，

本實施例將上行文件經(jīng)過在父線程解壓和解密處理的數(shù)據(jù)包分發(fā)給子線程進(jìn)行解析處理，改變現(xiàn)有技術(shù)只能對數(shù)據(jù)包進(jìn)行順序處理的缺陷，達(dá)到成倍提高協(xié)議解析速度的效果。

實施例二

本實施例與實施例一類似，不同之處在于，本實施例在步驟s2中，主進(jìn)程生成固定個數(shù)的子進(jìn)程，每個子進(jìn)程生成固定個數(shù)的父線程。

而在步驟s4中，每個父線程根據(jù)相應(yīng)數(shù)據(jù)包的數(shù)量和/或大小生成相應(yīng)個數(shù)的子線程。

本實施例采用的與實施例一一致的每個主進(jìn)程生成固定個數(shù)的子進(jìn)程，每個子進(jìn)程又生成固定個數(shù)的父線程，但是，本實施例的每個父線程生成的子線程個數(shù)不固定，本實施例中，為了在提高處理速度的同時達(dá)到節(jié)省空間，以及子線程的數(shù)量盡量適合當(dāng)前上行文件生成的數(shù)據(jù)包的數(shù)量，父線程生成子線程個數(shù)是可變的，下面在生成五個子進(jìn)程、五個父線程的情況下進(jìn)行具體說明：

其中主進(jìn)程與實施例一一樣用于接收上行文件，同時將上行文件分發(fā)給五個子進(jìn)程，子進(jìn)程又將自己接收到的所有上行文件分發(fā)給各自下面的五十個父線程，父線程對上行文件進(jìn)行解壓和解密處理，通常每個上行文件經(jīng)過父線程的解壓和解密處理后生成成千上萬個數(shù)據(jù)包，現(xiàn)有技術(shù)中每一個數(shù)據(jù)包的處理方式相同，每當(dāng)一個線程完成一個上行文件的解壓解密操作之后，對該上行文件中對每個數(shù)據(jù)包(packet)的處理采用的是順序處理，解析效率極低，而本實施例的每個父線程在將上行文件解壓和解密處理后得到若干個數(shù)據(jù)包，由負(fù)載均衡器對數(shù)據(jù)包的數(shù)量和大小進(jìn)行評估，然后根據(jù)數(shù)據(jù)包的數(shù)量和大小在相應(yīng)的父線程下生成合適個數(shù)的子線程，例如，當(dāng)一個父線程完成對一個上行文件的解密和解壓處理后得到了500個大小相等的數(shù)據(jù)包，則可以生成50個子線程，由父線程將500個數(shù)據(jù)包分發(fā)給其下面的五十個子線程，此時，如果每個子線程處理順利的話，每個子線程會處理10個數(shù)據(jù)包，此時，屬于最理想狀態(tài)，直到結(jié)束解析的最后一刻，所有的子線程均處于工作狀態(tài)，不浪費一點資源，當(dāng)然，每個上行文件生成的數(shù)據(jù)包可能會比500個多很多，每個數(shù)據(jù)包的大小可能也會不一樣，當(dāng)數(shù)據(jù)包具有多種大小種類的時候，則根據(jù)數(shù)據(jù)包個數(shù)的時候同時根據(jù)數(shù)據(jù)包的大小生成子線程個數(shù)，例如在對數(shù)據(jù)包進(jìn)行解析的過程中，最開始具有五十個子線程，當(dāng)對數(shù)據(jù)包解析快結(jié)束的時候，有多個子線程處于空閑狀態(tài)且已沒有多余的數(shù)據(jù)包需要解析，則自動釋放子線程；再如，當(dāng)一個上行文件的數(shù)據(jù)包的個數(shù)足夠少的時候，則只生成與數(shù)據(jù)包個數(shù)一樣的子線程；而當(dāng)一個上行文件具有很多不同規(guī)格的數(shù)據(jù)包的時候，也需要將數(shù)據(jù)包的規(guī)格在生成子線程個數(shù)的考慮范圍內(nèi)，例如可參考一個上行文件所有數(shù)據(jù)包的規(guī)格總和生成子線程；當(dāng)一個上行文件的數(shù)據(jù)包個數(shù)具有大量的數(shù)據(jù)包的時候，可以在允許的范圍內(nèi)生成最多的子線程以滿足需要。

當(dāng)然子線程生成個數(shù)還可以隨著其他一些情況的改變而改變，例如，該上行文件的處理速度要求、系統(tǒng)工作環(huán)境等。

本實施例能夠根據(jù)數(shù)據(jù)包的大小和數(shù)量靈活變化子線程的個數(shù)，既能夠提高解析速度，又能夠最大程度節(jié)省空間和進(jìn)一步提高解析速度。

實施例三

本實施例與實施例二類似，不同之處在于，本實施例在步驟s2中，主進(jìn)程生成固定個數(shù)的子進(jìn)程；

而每個子進(jìn)程根據(jù)相應(yīng)上行文件的數(shù)量和/或大小生成相應(yīng)個數(shù)的父線程；

以及，每個所述的父線程根據(jù)相應(yīng)數(shù)據(jù)包的數(shù)量和/或大小生成相應(yīng)個數(shù)的子線程。

本實施例采用的與實施例一一致的每個主進(jìn)程生成固定個數(shù)的子進(jìn)程，但是，本實施例的每個子進(jìn)程生成父線程的個數(shù)不固定，每個父線程生成的子線程個數(shù)也不固定，本實施例中，為了在提高處理速度的同時達(dá)到節(jié)省空間，以及父線程的數(shù)量盡量適合當(dāng)前上行文件的數(shù)量，以及子線程的數(shù)量盡量適合當(dāng)前上行文件生成的數(shù)據(jù)包的數(shù)量，子進(jìn)程生成父線程個數(shù)是可變的，父線程生成子線程個數(shù)也是可變的。

本實施例不僅能夠根據(jù)數(shù)據(jù)包的大小和數(shù)量靈活變化子線程的個數(shù)，而且能夠根據(jù)上行文件的數(shù)量和大小靈活變化父線程的個數(shù)，既能夠提高解析速度，又能夠最大程度節(jié)省空間和進(jìn)一步提高解析速度。

實施例四

本實施例與實施例三類似，不同之處在于，本實施例的主進(jìn)程生成子進(jìn)程的個數(shù)也是可變的，同樣是根據(jù)上下文件的大小和數(shù)量進(jìn)行改變，當(dāng)然此處生成子進(jìn)程個數(shù)的根據(jù)不限于上行文件的大小和數(shù)量，還可以根據(jù)其他環(huán)境。

實施例五

本實施例公開了一種基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理方法的基于多線程的成倍提高海量上行文件數(shù)據(jù)的協(xié)議解析處理系統(tǒng)。

本文中所描述的具體實施例僅僅是對本發(fā)明精神作舉例說明。本發(fā)明所屬技術(shù)領(lǐng)域的技術(shù)人員可以對所描述的具體實施例做各種各樣的修改或補(bǔ)充或采用類似的方式替代，但并不會偏離本發(fā)明的精神或者超越所附權(quán)利要求書所定義的范圍。

盡管本文較多地使用了主進(jìn)程、子進(jìn)程、父線程、子線程等術(shù)語，但并不排除使用其它術(shù)語的可能性。使用這些術(shù)語僅僅是為了更方便地描述和解釋本發(fā)明的本質(zhì)；把它們解釋成任何一種附加的限制都是與本發(fā)明精神相違背的。