專利名稱：一種可控的瀑布式文件推送的方法
技術(shù)領域：
本發(fā)明涉及通信網(wǎng)絡中的文件推送技術(shù)，尤其是涉及一種從服務器端發(fā)起的通過IP網(wǎng)絡可控的向海量客戶端進行文件推送的方法。
背景技術(shù)：
現(xiàn)有的文件下載一般有兩種模式■ HTTP、FTP等點對點下載。每個客戶端均連接到目標服務器進行下載。這種方式服務器端可以知道下載的狀態(tài)，但隨著客戶端的增多，服務器端的壓力增長迅速，一旦達到一定規(guī)模后，服務器端就無法支撐，導致較多客戶端無法下載?！?Peer-to-Peer (P2P)及衍生的多對多下載模式?？蛻舳嗽谙螺d時會搜索鄰近的其他源或下載客戶端，從這些點一起進行文件的下載。這種方式使得下載較為迅速，對服務器端壓力也較小。但是這種方式依賴于源上的內(nèi)容，對服務器端而言下載狀態(tài)不可知，且客戶端存在下載到一定程度后無法繼續(xù)下載的問題。HTTP/FTP或P2P的下載方式均是由客戶端主動發(fā)起去獲取文件，是Pull模式。現(xiàn)有的由服務器端主動發(fā)起，將文件Push到客戶端的方式一般為客戶端定時向服務器端發(fā)起請求，詢問是否需要下載及需下載的文件。這種方式主要存在以下弊端(I)客戶端定時發(fā)起詢問。在較多客戶端的環(huán)境下，鑒于服務器端的性能，不得不將詢問周期拉長，造成服務器端無法及時實現(xiàn)對對客戶端的行為控制。

(2)下載方式一般為HTTP或FTP等直接下載方式。受限于服務器端同時支持的下載連接數(shù)限制，該方法無法支撐較多客戶端同時在線，且對服務器端的網(wǎng)絡出口帶寬依賴性很強，造成推送效率的不足。

發(fā)明內(nèi)容
本發(fā)明的目的在于克服上述現(xiàn)有技術(shù)的不足，提供一種，通過抑制CE-BEM模型誤差，提高信道估計的準確性。本發(fā)明的技術(shù)解決方案如下一種可控的瀑布式文件推送方法，其特征在于，該方法包括服務器端推送流程的具體步驟如下步驟1.啟動推送任務，初始化輸入，包括需要推送的文件、提供下載服務的服務器和所有需要推送到的客戶端列表；步驟2.根據(jù)客戶端列表中客戶端網(wǎng)絡參數(shù)和性能參數(shù)(如客戶端的IP地址、接入網(wǎng)速等)，創(chuàng)建推送樹；步驟3.通知每個客戶端各自在推送樹中的位置；步驟4.將需要推送的大文件打包、拆分成一組小文件；步驟5.通知根節(jié)點的所有第一層子節(jié)點客戶端可以獲取所有小文件；步驟6.等待節(jié)點上報小文件獲取完成消息；
步驟7.接到節(jié)點上報小文件獲取完成消息，若該節(jié)點有子節(jié)點，則通知該節(jié)點的所有第一層子節(jié)點可以獲取該小文件；然后返回到步驟6，否則不操作。客戶端推送流程的具體步驟如下步驟1.初始化，令{可以下載的小文件集合}為空；步驟2.等待有可以下載的小文件的消息；步驟3.接收新的可以下載的小文件的通知，并將新接收到的小文件更新到{可以下載的小文件集合}中；步驟4.下載{可以下載的小文件集合}中的第一個小文件；步驟5.當下載完成一個小文件后，對該小文件的合法性進行驗證，如果驗證結(jié)果為合法，則通知該客戶端的所有下一層子節(jié)點客戶端可以獲取該小文件，并執(zhí)行步驟7，否貝U，執(zhí)行步驟6，下載下一個小文件；步驟6. 重新下載該小文件，并對該小文件的合法性進行驗證，直至驗證結(jié)果為合法;步驟7.判斷是否所有可以下載的小文件均已下載完成，如否，則下載{可以下載的小文件集合}中的下一個小文件，并返回步驟5，如是，則執(zhí)行步驟8 ;步驟8.判斷是否所有需要下載的小文件均已下載完成，如是，則執(zhí)行步驟9，否則等待新的可以下載的小文件的通知，并返回步驟2 ;步驟9.合成大文件，并對大文件的合法性進行驗證，如果驗證結(jié)果為合法，則則下載完成，否則，刪除所有已經(jīng)下載的小文件，返回步驟3。服務器端同時還對上述文件推送過程進行監(jiān)控，具體監(jiān)控步驟如下步驟1.啟動監(jiān)控；步驟2.監(jiān)控是否有需要推送的文件、新客戶端的加入、是否有客戶端異常；步驟3.若有需要推送的文件，則啟動服務器端推送流程，輸出包括需要推送的文件、提供下載服務的服務器、所有需要推送到的客戶端列表；否則休眠后繼續(xù)監(jiān)控；(客戶端各自的客戶端推送流程開機后即自動啟動，常駐系統(tǒng)中)若有新的客戶端加入，則啟動客戶端擴容流程，輸出為新加入的客戶端和推送任務；否則休眠后繼續(xù)監(jiān)控；若有客戶端異常，則啟動服務器端異常處理流程，輸出為異常的客戶端和推送任務；否則休眠后繼續(xù)監(jiān)控。所述的客戶端擴容流程的具體步驟如下步驟1.啟動客戶端擴容流程，初始化輸入，包括異?？蛻舳恕⑼扑腿蝿?；步驟2.根據(jù)新加入的客戶端的網(wǎng)絡參數(shù)及性能參數(shù)，將該客戶端插入到推送樹的某個節(jié)點(如節(jié)點A)，成為其子節(jié)點；步驟3.通知該客戶端節(jié)點對應的父節(jié)點(節(jié)點A)其在推送樹中的變化；步驟4.通知該客戶端所有的下載任務；步驟5.從其父節(jié)點處開始依次從父節(jié)點處開始下載；步驟6.客戶端的流程同本文中的客戶端流程。所述的服務器端異常處理流程的具體步驟如下步驟1.啟動異常處理流程，初始化輸入，包括異常的客戶端、推送任務；
步驟2.在推送樹中，將異常節(jié)點的位置由其第一個子節(jié)點進行替換，其他子節(jié)點成為替換后的節(jié)點的子節(jié)點，并逐層將第一個子節(jié)點的第一個子節(jié)點升級，直到葉子節(jié)點結(jié)束，如此，形成一顆新的推送樹；步驟3.通知推送樹中父節(jié)點或子節(jié)點發(fā)生變化的節(jié)點各自在推送樹中的位置變化；步驟4.通知推送樹中父節(jié)點發(fā)生變化的節(jié)點進行文件下載的源位置變化，并開始各自新的客戶端流程；步驟5.將被替換下的節(jié)點單獨紀錄，通知開始補償流程，啟動補償流程，輸出為推送任務、進入補償流程的客戶端列表。所述的補償流程的具體步驟如下步驟1.啟動補償流程，初始化輸入，包括進入補償流程的客戶端、推送任務；步驟2.整理該客戶端需下載的小文件及已下載的小文件信息，得出缺失小文件集合;步驟3.通知該客戶端依次從服務器或補償服務器上直接下載缺失的小文件，并進行合法性驗證。驗證通過則進行下一個小文件的下載，否則重新下載該小文件；步驟4.若所有需要下載的小文件已經(jīng)下載完成，則合成大文件，并進行合法性驗證，驗證通過則下載完成，否則重新下載。本發(fā)明原理包括客戶端組網(wǎng)策略文件的推送策略兩部分?？蛻舳私M網(wǎng)策略將需要推送到的客戶端進行分層、分組。針對所有在線客戶端，根據(jù)各個客戶端所處的網(wǎng)絡位置、帶寬等網(wǎng)絡環(huán)境信息，服務器將客戶端分成若干層，每層又分成若干組，最終形成一顆多叉樹。每個客戶端根據(jù)服務器端的指派，屬于且僅屬于推送樹中的某個除了根節(jié)點之外的節(jié)點；樹的根節(jié)點是服務器。根據(jù)實際網(wǎng)絡情況及服務器端的性能，樹的層數(shù)和子節(jié)點數(shù)均可以自由擴展。在單臺下載服務器的情況下，文件推送網(wǎng)絡組是一棵多叉樹；若有多臺下載服務器，則文件推送網(wǎng)絡是擴展成為一個森林。服務器端和客戶端均集成實時通訊客戶端，使得客戶端之間、客戶端與服務器端之間可以實時通訊。服務器端根據(jù)所有在線客戶端的網(wǎng)絡條件及性能進行推送網(wǎng)絡的組建和維護。文件的推送策略文件推送所有過程均由服務器端控制，包括需獲取的內(nèi)容、獲取的時間、獲取的源等，即服務器端控制及通知每一臺客戶端各自的需獲取的內(nèi)容，無論該客戶端位于IP網(wǎng)絡的哪個位置。文件推送到各客戶端的內(nèi)容完全一致。文件的推送采用瀑布法。文件由節(jié)點推送給它的所有子節(jié)點，其子節(jié)點下載完成后再推送給它的子節(jié)點，以此類推，直到所有葉子節(jié)點獲得文件為止。即>服務器端(根節(jié)點)推送給其位于樹的第一層的子節(jié)點；>第一層的節(jié)點獲取完成后推送給位于樹的第二層各自的子節(jié)點；>第二層的節(jié)點獲取完成后推送給位于樹的第三層各自的子節(jié)點； >以此類推，直到所有葉子節(jié)點的客戶端獲取完成。對于音視頻等較大的文件，采取將大文件拆分成一組連續(xù)的小文件的集合，以提高文件推送效率。若文件大小大于某個閾值，則被分拆成多個文件大小不超過閾值的小文件；若文件不超過該閾值，則分拆成I個文件，即文件本身。所述的大文件是指被分拆前的文件，所述的小文件是分拆后的文件。例1，需要推送的文件大小為480MB，閾值為50MB，則分拆成一組不超過50MB的小文件。例2 :需要推送的文件大小為40MB，閾值為50MB，則分拆成的小文件只有I個?，F(xiàn)有的文件推送一般由客戶端主動發(fā)起，定時向服務器端輪詢是否需要下載，然后發(fā)起下載。在較多客戶端的環(huán)境下，受限于服務器端的性能，這種方式使得服務器端無法及時實現(xiàn)對客戶端的行為控制，下載無法兼顧快速和可控，且服務器端可支撐的客戶端數(shù)
量有限。本發(fā)明采用實時通訊技術(shù)，使得客戶端之間、客戶端與服務器端之間可以實時通訊。通過實時通訊機制，服務器端可以主動的對客戶端進行組網(wǎng)及控制客戶端的文件獲取行為，減少客戶端在獲取文件時對服務器端的依賴，降低對服務器端設備數(shù)量及網(wǎng)絡出口帶寬的要求。


圖1是服務器端監(jiān)控流程圖。圖2是服務器端推送流程圖。圖3是客戶端推送流程圖。圖4是文件推送中的客戶端擴容流程圖。圖5是服務器端異常 處理流程圖。圖6是服務器端補償流程圖。
具體實施例方式下面結(jié)合實施例和附圖對本發(fā)明作進一步說明，但不應以此限制本發(fā)明的保護范圍。請先參閱圖2，圖2是服務器端推送流程圖，如圖所示，服務器端推送流程的具體步驟如下步驟1.啟動推送任務，初始化輸入，包括需要推送的文件、提供下載服務的服務器和所有需要推送到的客戶端列表；步驟2.根據(jù)客戶端列表中客戶端網(wǎng)絡參數(shù)和性能參數(shù)(如IP地址、網(wǎng)速、允許的協(xié)議等)，創(chuàng)建推送樹；步驟3.通知每個客戶端各自在推送樹中的位置；步驟4.將需要推送的大文件打包、拆分成一組小文件；步驟5.通知根節(jié)點的所有第一層子節(jié)點客戶端可以獲取所有小文件；步驟6.等待節(jié)點上報小文件獲取完成消息；步驟7.接到節(jié)點上報小文件獲取完成消息，若該節(jié)點有子節(jié)點，則通知該節(jié)點的所有第一層子節(jié)點可以獲取該小文件；然后返回到步驟6，否則不操作。圖3是客戶端推送流程圖，如圖所示，客戶端推送流程的具體步驟如下
步驟1.初始化，令{可以下載的小文件集合}為空；步驟2.等待有可以下載的小文件的消息；步驟3.接收新的可以下載的小文件的通知，并將新接收到的小文件更新到{可以下載的小文件集合}中；步驟4.下載{可以下載的小文件集合}中的第一個小文件；步驟5.當下載完成一個小文件后，對該小文件的合法性進行驗證，如果驗證結(jié)果為合法，則通知該客戶端的所有下一層子節(jié)點客戶端可以獲取該小文件，并執(zhí)行步驟7，否貝U，執(zhí)行步驟6，下載下一個小文件；步驟6.重新下載該小文件，并對該小文件的合法性進行驗證，直至驗證結(jié)果為合法;步驟7.判斷是否所有可以下載的小文件均已下載完成，如否，則下載{可以下載的小文件集合}中的下一個小文件，并返回步驟5，如是，則執(zhí)行步驟8 ;步驟8.判斷是否所有需要下載的小文件均已下載完成，如是，則執(zhí)行步驟9，否則等待新的可以下載的小文件的通知，并返回步驟2 ;步驟9.合成大文件，并對大文件的合法性進行驗證，如果驗證結(jié)果為合法，則則下載完成，否則，刪除所有已經(jīng)下載的小文件，返回步驟3。創(chuàng)建例如在一次推送中，有5個客戶端需要下載相同內(nèi)容，需要創(chuàng)建推送樹。這 5 個客戶端的外網(wǎng) IP 分別是 61. 25. 15. 15,61. 25. 15. 81,171. 7. 78. 45,171. 6. 5. 34，180. 16. 123. 234。一般而言，同一個互聯(lián)網(wǎng)接入商分配出來的IP地址的前綴相同或相鄰，而且同一互聯(lián)網(wǎng)接入商提供的設備之間的互聯(lián)網(wǎng)絡較快。因此，可以針對這5個客戶端創(chuàng)建一顆這樣的推送樹根節(jié)點為服務器；根節(jié)點的子節(jié)點分別為61.25. 15. 15,171. 7. 78. 45,180. 16. 123. 234 ；節(jié)點61. 25. 15. 15 的子節(jié)點為:61. 25. 15. 81 ；節(jié)點171. 7. 78. 45 的子節(jié)點為:171. 6. 5. 34。服務器端對文件推送過程還進行監(jiān)控，監(jiān)控流程如圖1所示，具體步驟如下步驟1.啟動監(jiān)控；步驟2.監(jiān)控是否有需要推送的文件、新客戶端的加入、是否有客戶端異常；步驟3.若有需要推送的文件，則啟動服務器端推送流程，輸出包括需要推送的文件、提供下載服務的服務器、所有需要推送到的客戶端列表；否則休眠后繼續(xù)監(jiān)控；(客戶端各自的客戶端推送流程開機后即自動啟動，常駐系統(tǒng)中)若有新的客戶端加入，則啟動客戶端擴容流程，輸出為新加入的客戶端和推送任務；否則休眠后繼續(xù)監(jiān)控；若有客戶端異常，啟動服務器端異常處理流程，輸出為異常的客戶端和推送任務；否則休眠后繼續(xù)監(jiān)控。圖4是文件推送中的客戶端擴容流程，如圖所示，在一次文件推送過程中，有一個新的客戶端也需要獲取相同內(nèi)容，則需要進行文件推 送中的客戶端擴容流程。步驟為步驟1.選取原推送樹中與新加入的客戶端的IP地址相鄰的一個葉子節(jié)點(A)Jf新加入的客戶端(B)添加成為這個葉子節(jié)點(A)的子節(jié)點；
步驟2.通知原葉子節(jié)點(A)增加了一個子節(jié)點(B)；步驟3.通知節(jié)點(B)從父節(jié)點(A)下載所有節(jié)點(A)已經(jīng)下載完成的小文件。圖5是服務器端異常處理流程圖，如圖所示，在一次文件推送過程中，有一個節(jié)點(A)發(fā)生下載異常，無法繼續(xù)為它的子節(jié)點提供內(nèi)容下載服務，則需要進行服務器端異常處理流程。步驟為步驟1.在原推送樹中，節(jié)點(A)的父節(jié)點為節(jié)點(B);節(jié)點(A)的第一個葉子節(jié)點(C)。則將節(jié)點(B)的子節(jié)點(A)替換成節(jié)點(C)；步驟2.將節(jié)點(A)除節(jié)點(C)外的所有其他第一層子節(jié)點均掛載到節(jié)點(C)，成為節(jié)點(C)的子節(jié)點；步驟3.將節(jié)點(C)的原所有子節(jié)點進行類似操作，直到葉子節(jié)點；步驟4.通知所有父節(jié)點或子節(jié)點發(fā)生變化的節(jié)點各自在推送樹中新的位置。圖6是服務器端補償流程圖，如圖可知，在一次文件推送過程中發(fā)生異常，假設此提送公分為10個小文件，該客戶端已經(jīng)下載完成3個小文件，則服務器端補償流程的步驟為步驟1.通知該客戶端從服務器直接下載缺失文件4 10 ;步驟2.客戶端更新可以下`載的文件集合；步驟3.客戶端依次從服務器端下載小文件4 10 ;步驟4.若客戶端下載完成一個小文件，則進行該小文件合法性驗證；若小文件合法性驗證不通過，則需要重新下載該小文件，返回到步驟2 ;若小文件合法性驗證通過，則判斷是否所有需要下載的小文件均下載完成；步驟5.若不是所有的小文件均下載完成，則返回步驟3，繼續(xù)下載剩余的小文件；若所有小文件均下載完成，則將從原父節(jié)點下載的1、2、3及從服務器下載的4 10，合成一個大文件；步驟6.合成的大文件合法性驗證通過，則下載完成；否則需要全部從服務器端下載所有小文件，返回到步驟I。試驗表明，在有大量客戶端的環(huán)境下，本發(fā)明使得文件可以主動的從服務器端快速、可控的推送到各個客戶端，避免了現(xiàn)有方法無法在同時做到快速和可控的弊端，也減少了服務器端的設備數(shù)量及網(wǎng)絡帶寬要求。
權(quán)利要求
1.一種可控的瀑布式文件推送方法，其特征在于，該方法包括 服務器端推送流程的具體步驟如下 步驟1.啟動推送任務，初始化輸入，包括需要推送的文件、提供下載服務的服務器和所有需要推送到的客戶端列表； 步驟2.根據(jù)客戶端列表中客戶端的網(wǎng)絡參數(shù)和性能參數(shù)，創(chuàng)建推送樹； 步驟3.通知每個客戶端各自在推送樹中的位置； 步驟4.將需要推送的大文件打包、拆分成一組小文件； 步驟5.通知根節(jié)點的所有第一層子節(jié)點客戶端可以獲取的所有小文件； 步驟6.等待節(jié)點上報小文件獲取完成消息； 步驟7.接到節(jié)點上報小文件獲取完成消息，若該節(jié)點有子節(jié)點，則通知該節(jié)點的所有第一層子節(jié)點可以獲取的小文件，然后返回到步驟6，否則不操作。
客戶端推送流程的具體步驟如下 步驟1.初始化，令{可以下載的小文件集合}為空； 步驟2.等待有可以下載的小文件的消息； 步驟3.接收新的可以下載的小文件的通知，并將新接收到的小文件更新到{可以下載的小文件集合}中； 步驟4.下載{可以下載的小文件集合}中的第一個小文件； 步驟5.當下載完成一個小文件后，對該小文件的合法性進行驗證，如果驗證結(jié)果為合法，則通知該客戶端的所有下一層子節(jié)點客戶端可以獲取該小文件，并執(zhí)行步驟7，否則，執(zhí)行步驟6，下載下ー個小文件； 步驟6.重新下載該小文件，并對該小文件的合法性進行驗證，直至驗證結(jié)果為合法；步驟7.判斷是否所有可以下載的小文件均已下載完成，如否，則下載{可以下載的小文件集合}中的下一個小文件，并返回步驟5，如是，則執(zhí)行步驟8 ； 步驟8.判斷是否所有需要下載的小文件均已下載完成，如是，則執(zhí)行步驟9，否則等待新的可以下載的小文件的通知，并返回步驟2 ; 步驟9.合成大文件，并對大文件的合法性進行驗證，如果驗證結(jié)果為合法，則則下載完成，否則，刪除所有已經(jīng)下載的小文件，返回步驟3。
2.根據(jù)權(quán)利要求1所述的可控的瀑布式文件推送方法，其特征在于，服務器端對文件推送的全過程進行監(jiān)控，具體步驟如下 步驟1.啟動監(jiān)控； 步驟2.監(jiān)控是否有需要推送的文件、新客戶端的加入、是否有客戶端異常； 步驟3.若有需要推送的文件，則啟動服務器端推送流程，輸出包括需要推送的文件、提供下載服務的服務器、所有需要推送到的客戶端列表；否則休眠后繼續(xù)監(jiān)控； 步驟4.若有新的客戶端加入，則啟動客戶端擴容流程，輸出為新加入的客戶端和推送任務；否則休眠后繼續(xù)監(jiān)控； 若有客戶端異常，則啟動服務器端異常處理流程，輸出為異常的客戶端和推送任務；否則休眠后繼續(xù)監(jiān)控。
3.根據(jù)權(quán)利要求2所述的可控的瀑布式文件推送方法，其特征在于，所述的客戶端擴容流程的具體步驟如下步驟1.啟動客戶端擴容流程，初始化輸入，包括異?？蛻舳恕⑼扑腿蝿眨? 步驟2.根據(jù)新加入的客戶端的網(wǎng)絡參數(shù)及性能參數(shù)，將該客戶端插入到推送樹中，成為其某個節(jié)點的子節(jié)點； 步驟3.通知該客戶端節(jié)點對應的父節(jié)點在推送樹中的變化； 步驟4.通知該客戶端所有的下載任務； 步驟5.從其父節(jié)點處開始依次從父節(jié)點處開始下載； 步驟6.客戶端的流程同本文中的客戶端流程。
4.根據(jù)權(quán)利要求2所述的可控的瀑布式文件推送方法，其特征在于，所述的服務器端異常處理流程的具體步驟如下 步驟1.啟動異常處理流程，初始化輸入，包括異常的客戶端、推送任務； 步驟2.在推送樹中，將異常節(jié)點的位置由其第一個子節(jié)點進行替換，其他子節(jié)點成為替換后的節(jié)點的子節(jié)點，并逐層將第一個子節(jié)點的第一個子節(jié)點升級，直到葉子節(jié)點結(jié)束，如此，形成一顆新的推送樹； 步驟3.通知推送樹中父節(jié)點或子節(jié)點發(fā)生變化的節(jié)點各自在推送樹中的位置變化；步驟4.通知推送樹中父節(jié)點發(fā)生變化的節(jié)點進行文件下載的源位置變化，并開始各自新的客戶端流程； 步驟5.將被替換下的節(jié)點單獨紀錄，通知開始補償流程，啟動補償流程，輸出為推送任務、進入補償流程的客戶端列表。
5.根據(jù)權(quán)利要求4所述的可控的瀑布式文件推送方法，其特征在于，所述的補償流程的具體步驟如下 步驟1.啟動補償流程，初始化輸入，包括進入補償流程的客戶端、推送任務； 步驟2.整理該客戶端需下載的小文件及已下載的小文件信息，得出缺失小文件集合；步驟3.通知該客戶端依次從服務器或補償服務器上直接下載缺失的小文件，并進行合法性驗證。驗證通過則進行下一個小文件的下載，否則重新下載該小文件； 步驟4.若所有需要下載的小文件已經(jīng)下載完成，則合成大文件，并進行合法性驗證，驗證通過則下載完成，否則重新下載。
全文摘要
一種可控的瀑布式文件推送方法，包括服務器端推送流程中將需要推送到的客戶端進行分層、分組，客戶端推送流程中由服務器端控制，包括需獲取的內(nèi)容、獲取的時間、獲取的源等，即服務器端控制及通知每一臺客戶端各自的需獲取的內(nèi)容，無論該客戶端位于IP網(wǎng)絡的哪個位置。本發(fā)明采用實時通訊技術(shù)，使得客戶端之間、客戶端與服務器端之間可以實時通訊，服務器端可以主動的對客戶端進行組網(wǎng)及控制客戶端的文件獲取行為，減少客戶端在獲取文件時對服務器端的依賴，降低對服務器端設備數(shù)量及網(wǎng)絡出口帶寬的要求。
文檔編號H04L29/08GK103036898SQ201210563639
公開日2013年4月10日 申請日期2012年12月21日 優(yōu)先權(quán)日2012年12月21日
發(fā)明者潘海斌, 顧亞平, 林海, 張俊 申請人:上?，F(xiàn)代先進超精密制造中心有限公司