2]步驟501:各個接收機啟動，并行向位于服務器側的控制機發送各自的數據請求消息以請求數據，在各個數據請求消息中均包含有請求數據描述字段，以用于描述所請求的數據。
[0123]在此步驟，示范性地，接收機請求(ASK)Data_Vers1n= 0 ；Seq = 0 ；Global_flag=0的數據。
[0124]步驟502:控制機接收到各個數據請求消息之后，分別讀取各個數據請求消息中的數據種類命令號(cmd)，如果發現數據請求消息中的數據種類命令號與自身已有的數據的數據種類命令號不匹配，則丟棄數據請求消息；如果發現數據請求消息中的數據種類命令號與自身已有的數據匹配，則繼續讀取數據請求消息中的數據版本號(Data_VerS1n)、數據序號(seq)和數據類型(Global_flag)，并且與自身已有的數據的相應的數據版本號、數據序號和進行數據類型匹配。當數據序號、數據類型和數據版本號中至少有一個不匹配時，則判定讀取數據請求消息中的請求數據描述字段不合法，并向該不合法的讀取數據請求消息所對應的接收機發送狀態重置消息(reset)，以重置接收機狀態。在狀態重置消息中包含控制機已有數據的當前cmd的vers1n (n)、Total_count (m)、global狀態。
[0125]在此步驟，示范性地，由于接收機請求(ASK)Data_Vers1n = 0 ；Seq = 0 ；Global_flag = 0與控制機已有數據不匹配，因此在狀態重置消息中返回Data_Vers1n = η ；total_count = m ；Global_f lag = 1 的字段信息。
[0126]步驟503:接收機收到狀態重置消息后，按照狀態重置消息的指定重新請求數據，重新發送更新后的數據請求消息。
[0127]在此步驟，示范性地，接收機請求Data_Vers1n = n ；Seq = 0 ；Global_flag = 1的數據。
[0128]接收機每次發送數據請求消息后在預定時間(比如3s)內沒有收到回包，則會再重發該數據請求消息(應對丟包情況)。
[0129]步驟404:當等待3秒之后，如果依然沒有收到數據，則再次發送數據請求消息。接收機請求 Data_Vers1n = n ；Seq = 0 ；Global_flag = 1 的數據。
[0130]步驟505:控制機讀取數據請求消息,并將數據請求消息中的cmd、vers1n、seq和global_flag進行匹配，校驗通過后組裝Data_pkg_count個數據，組裝為Data消息以發送給接收機。Data消息是server端發送給接收機的消息,是根據接收機發來的數據請求消息準備數據，將接收機需要的數據發送給接收機。
[0131]在這里，示范性地，接收機返回Data_Vers1n = n ；Seq = 0 ；Global_flag = 1 的數據。
[0132]步驟506?507:當接收機基于本次要更新的數據總量(Total_count)字段判定收到最后一個數據后，會重置狀態，將vers1n自動加1，再發送數據請求消息以請求下一個版本的數據；控制機收到數據請求消息后發現版本號超前，則丟棄該消息。
[0133]其中，用戶可以在各種接收機或控制機上執行本發明的處理，這些接收機或控制機可以包括但是不局限于:功能手機、智能手機、掌上電腦、個人電腦(PC)、平板電腦或個人數字助理(PDA)，等等。
[0134]以上雖然詳細羅列了接收機或控制機的具體實例，本領域人員可以意識到，這些羅列僅是闡述目的，并不用于限定本發明實施方式的保護范圍。
[0135]本發明的數據分發方法具有如下特點:
[0136](1)、無狀態:在整個流程中，數據發送端(控制機)不保存數據傳輸狀態，由各個數據接收端(接收機)維護自己的數據傳輸狀態。對于數據接收端(接收機)來說，都是獨占數據發送端(控制機)的，各個數據接收端(接收機)之間保持相互獨立。
[0137](2)、高并發，快速:可以很好的支持向各個數據接收端(接收機)并發的下發數據，并且其并發量理論上可以無限多，相互之間不會有影響，數據發送端(控制機)的帶寬資源由所有的接收機共享。
[0138](3)、無需運維:數據分發是由數據接收端(接收機)主動發起請求，因此數據發送端(控制機)無需維護接收機列表。有新機器加入時，數據發送端(控制機)無需感知。
[0139](4)、充分利用帶寬:在數據發送端(控制機)給接收機A回復消息后，由于存在網絡延遲，數據發送端(控制機)在收到接收機A的下一個數據請求消息之前，會存在空閑時間。這段空閑時間可以用于對接收機B、C、D等機器服務，這樣數據發送端(控制機)的cpu資源和帶寬資源會被充分利用。當并發量大時，數據發送端(控制機)的網絡流量可以達到網卡上限。
[0140](5)、無流量穿越:數據發送端(控制機)每次發送完數據后需要等待下一個數據請求消息，才會繼續發送。因此當下發的數據量大時，數據接收端(接收機)和數據發送端(控制機)之間會存在大量的空閑時間，不會一直都在發送數據，這樣天然的避免了對公共帶寬資源的突發占用。當數據接收端(接收機)數據多時，也不會出現流量疊加。由于各個數據接收端(接收機)不會全部分布在同一個機房的同一個機架上，因此所經過的交換機和路由器不會完全相同，這樣就不會對某個核心節點的交換設備造成壓力。
[0141](6)、方便監控:各個數據接收端(接收機)可以定時(比如3s)發送數據請求消息，這就形成了一個心跳消息，在數據發送端(控制機)可以直接觀察到有哪些接收機連接到數據發送端(控制機)上。根據數據請求消息的data_vers1n,也可直接實時的觀察到哪些接收機更新完成，哪些接收機還未完成更新。
[0142](7)、針對網絡延遲大的加速下發:對于異地的接收機進行下發時，速度慢主要是由于網絡延遲大。對于這樣的機器只需要增大數據請求消息的Data_pkg_COunt(滑動窗口)即可。假設當滑動窗口為1時，下發時間為T。如果修改Data_pkg_COunt為n，則下發的時間就會變為t = T/n，t理論上可以接近一個網絡延遲的時間片。
[0143](8)、單一和群體下發都支持:因為數據發送端(控制機)是無狀態，接收機相互之間獨立，所以當別的接收機都下發完成后，可以對某個新加入的機器進行單獨的重新下發。當需要群體下發時，只需要數據發送端(控制機)修改下數據版本號(加一，變成接收機需求的版本號)，即可開始群體下發。單一下發一般由接收機發起，群體下發一般由數據發送端(控制機)發起。
[0144](9)、無阻塞現象:相對于以前的串行下發，串行變并行，單機的故障自然不會影響整體下發的速度。
[0145](10)、增量更新和全量更新:針對數據量大的情況，本發明的Global_flag字段提供了兩種(全量/增量)數據更新方式，增量更新時會將數據變化的部分分發下去，由業務方根據業務邏輯自己更新到全量數據中。
[0146]本發明中，數據發送端(控制機)的無狀態和接收機的獨占式文件更新，保證了可以支持無限多的接收機同時進行更新，進而突破了數據傳輸協議一直以來都是點到點的串行傳輸瓶頸，成為一對多的并行應用層數據傳輸方法。
[0147]基于上述詳細分析，本發明實施方式還提出了一種數據接收裝置。
[0148]圖6為根據本發明實施方式數據接收裝置的結構圖。
[0149]如圖6所示，包括數據請求消息發送單元602和數據接收單元601，其中:
[0150]數據請求消息發送單元602，用于創建數據請求消息，所述數據請求消息包括請求數據描述字段，并發送所述數據請求消息；
[0151]數據接收單元601，用于接收對應于所述請求數據描述字段的數據，其中所述數據是當所述請求數據描述字段合法時并行返回的。
[0152]在一個實施方式中，還包括:
[0153]狀態重置消息接收單元604，用于接收狀態重置消息，所述狀態重置消息是當所述請求數據描述字段不合法時并行返回的，而且在所述狀態重置消息中包含數據描述信息；
[0154]數據請求消息發送單元602，進一步用于基于所述數據描述信息構建更新的數據請求消息，所述更新的數據請求消息包括更新的請求數據描述字段；
[0155]數據接收單元，進一步用于接收對應于所述更新的請求數據描述字段的數據，其中所述數據是當所述更新的請求數據描述字段合法時并行返回的。
[0156]在一個實施方式中，還包括:
[0157]所述請求數據描述字段包括數據種類命令號、數據序號、數據類型和數據版本號；其中:
[0158]當所述數據種類命令號與已有數據的數據種類命令號相匹配，且所述數據序號、數據類型和數據版本號中至少有一個與已有數據的數據序號、數據類型和數據版本號不匹配時，判定所述請求數據描述字段不合法；和/或
[0159]當所述數據種類命令號與已有數據的數據種類命令號相匹配，且所述數據序號、數據類型和數據版本號分別與已有數據的數據序號、數據類型和數據版本號匹配時，判定所述請求數據描述字段合法。
[0160]在一個實