專利名稱：基于MirrorLink協(xié)議的文件傳輸方法及裝置的制作方法
技術領域：
本發(fā)明涉及數據處理領域,更為具體地，涉及一種基于MirrorLink協(xié)議的文件傳輸方法和裝置。
背景技術：
隨著智能移動終端和車載終端的快速發(fā)展，將上述兩種設備結合起來使得使用價值最大化的要求越來越強烈。眾所周知，車載終端具有大屏幕的優(yōu)勢，而智能移動終端具有豐富的聯(lián)網功能，如果將兩者結合起來使用(例如，使用智能移動終端的網絡在車載終端顯示進行實時導航)，不僅可以提高用戶體驗，方便使用，而且可以實現資源整合復用。按照這種方式，一方面豐富了車載終端的功能，另一方面節(jié)約了成本。MirrorLink協(xié)議是為了應對上述場景而設計的一種協(xié)議，應用該協(xié)議可以將智能移動終端與車載終端緊密聯(lián)系起來。在MirrorLink協(xié)議中，將智能移動終端稱為MirrorLink服務端,將車載終 端稱為MirrorLink客戶端,通過將服務端(智能移動終端)的屏幕顯示及聲音傳輸到客戶端(車載終端)，實現在客戶端使用服務端提供的內容及服務的功能。圖1示出了基于MirrorLink協(xié)議在智能移動終端和車載終端之間實現的功能的示意圖。如圖1所示，MirrorLink實現的功能如下(I)將服務端的屏幕顯示內容傳輸到客戶端；(2)將服務端的聲音傳輸到客戶端；以及(3)將客戶端的用戶輸入，包括屏幕觸控信息、聲控信息等傳輸到服務端。通過上述功能的組合實現在車載終端使用智能移動終端提供的內容和服務的功能。只要支持MirrorLink協(xié)議，用戶就可以在車載終端撥打電話、上網、使用智能移動終端上的導航軟件等。從上可以看出，基于MirrorLink協(xié)議，可以實現智能移動終端與車載終端的連接，從而提高了整體使用價值。然而，MirrorLink協(xié)議卻不支持智能移動終端與車載終端間的文件傳輸，由此智能移動終端與車載終端之間不能實現完全“互聯(lián)”功能。因此,需要一種新的基于MirrorLink協(xié)議的文件傳輸方法和裝置,其能夠實現智能移動終端與車載終端之間的文件傳輸。

發(fā)明內容
鑒于上述，本發(fā)明的目的在于提供一種基于擴展的RFB協(xié)議實現的用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸方法，該文件傳輸方法能夠利用MirrorLink協(xié)議中的RFB協(xié)議實現智能移動終端與車載終端之間的文件傳輸。本發(fā)明的另一目的在于提供一種基于擴展的RFB協(xié)議實現的用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸裝置，具有上述文件傳輸裝置的智能移動終端和車載終端。根據本發(fā)明的一個方面，提供了一種用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸方法，其中，所述智能移動終端和車載終端中之一作為發(fā)送端，以及所述智能終端和車載終端中的另一個作為接收端，所述方法包括在接收到文件傳輸請求后，發(fā)送端將要被傳輸的文件的文件名封裝為第一報文，并作為文件傳輸過程的第一個報文發(fā)送給接收端；接收端基于所接收的第一報文，確認是否進行文件傳輸，如進行文件傳輸，則向發(fā)送端返回第二報文；在接收到返回的第二報文后，發(fā)送端將要被傳輸的文件封裝成第四報文或者一個或多個第三報文和第四報文，傳輸給所述接收端，其中，所述第一報文依次包括報文類型字段、報文子類型字段、Length字段以及Data字段，所述第二報文依次包括報文類型字段和報文子類型字段，所述第三報文和第四報文依次包括報文類型字段、報文子類型字段、報文序號字段、Length字段以及Data字段，其中，所述第一到第四報文的報文類型字段被賦予RFB協(xié)議中的同一預留報文號，所述第一到第四報文的報文子類型字段用于記錄被賦予預定定義且為發(fā)送端和接收端已知的第一、第二、第三和第四報文編號，所述第三和第四報文的報文序號字段用于記錄文件分塊傳輸時該報文中的文件分塊的序號，所述第一、第三和第四報文的Length字段用于記錄各自的Data字段的長度，所述第一報文的Data字段用于記錄文件名，以及第三和第四報文的Data字段用于記錄數據部分，其中，所述第一報文編號表明該報文是文件傳輸發(fā)起報文，第二報文編號表明該報文是文件傳輸應答報文，第三報文編號表明該報文是非最后一個報文的文件傳輸數據報文，以及第四報文編號表明該報文是作為最后一個報文的文件傳輸數據報文。 在上述方面的一個或多個示例中，在將所述第一報文發(fā)送給接收端后，如果接收到所述接收端返回的第五報文，則發(fā)送端不進行文件傳輸，其中，所述第五報文依次包括報文類型字段和報文子類型字段， 所述第五報文的報文類型字段用于記錄與第二報文中的報文類型相同的報文號，所述報文子類型字段用于記錄預定的第五報文編號，所述第五報文編號表明不進行文件傳輸。在上述方面的一個或多個示例中，在文件傳輸過程期間，如果接收端或者發(fā)送端接收到對端發(fā)送的第六報文，則中斷文件傳輸過程，其中，所述第六報文依次包括報文類型字段和報文子類型字段，所述第六報文的報文類型字段用于記錄與第二報文中的報文類型相同的報文號，以及所述報文子類型字段用于記錄預定的第六報文編號，所述第六報文編號表明中斷文件傳輸。根據本發(fā)明的另一方面，提供了一種用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸方法，其中，所述智能移動終端和車載終端中之一作為發(fā)送端，以及所述智能終端和車載終端中的另一個作為接收端，所述方法包括在接收到文件傳輸請求后，發(fā)送端為要被傳輸的文件分配文件ID ;發(fā)送端將要被傳輸的文件的文件名和所分配的文件ID封裝為第一報文，并作為文件傳輸過程的第一個報文發(fā)送給接收端；接收端基于所接收的第一報文中包含的文件ID，檢查該文件ID是否與正在傳輸的其它文件的文件ID沖突，在檢查出沒有沖突時，向發(fā)送端返回第二報文；以及在接收到所述接收端返回的第二報文后，發(fā)送端將要被傳輸的文件封裝成第四報文或者一個或多個第三報文和第四報文，傳輸給所述接收端，其中，所述第一報文依次包括報文類型字段、報文子類型字段、文件ID字段、Length字段以及Data字段，所述第二報文依次包括報文類型字段和報文子類型字段，所述第三報文和第四報文依次包括報文類型字段、報文子類型字段、文件ID字段、報文序號字段、Length字段以及Data字段，其中，所述第一到第四報文的報文類型字段被賦予RFB協(xié)議中的同一預留報文號，所述第一到第四報文的報文子類型字段用于記錄被賦予預定定義且為發(fā)送端和接收端已知的第一、第二、第三和第四報文編號，所述第一、第三和第四報文的文件ID字段用于記錄文件ID，所述第三和第四報文的報文序號字段用于記錄文件分塊傳輸時該報文中的文件分塊的序號，所述第一、第三和第四報文的Length字段用于記錄各自的Data字段的長度，所述第一報文的Data字段用于記錄文件名，以及第三和第四報文的Data字段用于記錄數據部分，其中，所述第一報文編號表明該報文是文件傳輸發(fā)起報文，第二報文編號表明該報文是文件傳輸應答報文，第三報文編號表明該報文是非最后一個報文的文件傳輸數據報文，以及第四報文編號表明該報文是作為最后一個報文的文件傳輸數據報文。在上述方面的一個或多個示例中，在將所述第一報文發(fā)送給接收端后，如果接收到所述接收端返回的第五報文，則發(fā)送端重新為要被傳輸的文件分配新文件ID，并且基于重新分配的新文件ID和文件名封裝成新的第一報文發(fā)送給所述接收端，其中，所述第五報文依次包括報文類型字段和報文子類型字段，所述第五報文的報文類型字段用于記錄與第二報文中的報文類型相同的報文號，所述報文子類型字段用于記錄預定的第五報文編號，所述第五報文編號表明所分配的文件ID與正在傳輸的其它文件的文件ID沖突。在上述方面的一個或多個示例中，在文件傳輸過程期間，如果接收端或者發(fā)送端接收到對端發(fā)送的第六報文，則中斷與所述第六報文中包含的文件ID對應的文件的文件傳輸過程，其中，所述第六報文依次包括報文類型字段、報文子類型字段和ID字段，所述第六報文的報文類型字段用于記錄與第二報文中的報文類型相同的報文號，所述報文子類型字段用于記錄預定的第六報文編號，所述第六報文編號表明中斷文件傳輸，以及所述ID字段記錄要被中斷傳輸的文件的ID。根據本發(fā)明的另一方面，提供一種用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸裝置，其中，所述智能移動終端和車載終端中之一作為發(fā)送端，以及所述智能終端和車載終端中的另一個作為接收端，所述文件傳輸裝置包括在發(fā)送端，所述文件傳輸裝置包括發(fā)送端報文生成單元，用于在接收到文件傳輸請求后，將要被傳輸的文件的文件名封裝為第一報文，以及在接收到所述接收端返回的第二報文后，將要被傳輸的文件封裝成第四報文或者一個或多個第三報文和第四報文；發(fā)送端通信單元，用于將發(fā)送端生成的報文發(fā)送給接收端，以及接收從接收端傳輸的報文，在接收端，所述文件傳輸裝置包括文件傳輸確認單元，用于基于所接收的第一報文，確認是否進行文件傳輸；接收端報文生成單元，用于在確認進行文件傳輸時，生成第二報文；以及接收端通信單元，用于將發(fā)送端生成的報文發(fā)送給接收端，以及接收從接收端傳輸的報文，其中，所述第一報文依次包括報文類型字段、報文子類型字段、Length字段以及Data字段，所述第二報文依次包括報文類型字段和報文子類型字段，所述第三報文和第四報文依次包括報文類型字段、報文子類型字段、報文序號字段、Length字段以及Data字段，其中，所述第一到第四報文的報文類型字段被賦予RFB協(xié)議中的同一預留報文號，所述第一到第四報文的報文子類型字段用于記錄被賦予預定定義且為發(fā)送端和接收端已知的第一、第二、第三和第四報文編號，所述第三和第四報文的報文序號字段用于記錄文件分塊傳輸時該報文中的文件分塊的序號，所述第一、第三和第四報文的Length字段用于記錄各自的Data字段的長度，所述第一報文的Data字段用于記錄文件名，以及第三和第 四報文的Data字段用于記錄數據部分，其中，所述第一報文編號表明該報文是文件傳輸發(fā)起報文，第二報文編號表明該報文是文件傳輸應答報文，第三報文編號表明該報文是非最后一個報文的文件傳輸數據報文，以及第四報文編號表明該報文是作為最后一個報文的文件傳輸數據報文。在上述方面的一個或多個示例中，所述文件傳輸裝置還可以包括文件傳輸中斷單元，位于發(fā)送端和接收端中，用于在文件傳輸過程期間，如果接收到對端發(fā)送的第六報文，則中斷文件傳輸過程，其中，所述第六報文依次包括報文類型字段和報文子類型字段，所述第六報文的報文類型字段用于記錄與第二報文中的報文類型相同的報文號，所述報文子類型字段用于記錄預定的第六報文編號，所述第六報文編號表明中斷文件傳輸。根據本發(fā)明的另一方面，提供了一種用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸裝置，其中，所述智能移動終端和車載終端中之一作為發(fā)送端，以及所述智能終端和車載終端中的另一個作為接收端，所述文件傳輸裝置包括在發(fā)送端，所述文件傳輸裝置包括文件ID分配單元，用于在接收到文件傳輸請求后，為要被傳輸的文件分配文件ID ;發(fā)送端報文生成單元，用于將要被傳輸的文件的文件名和所分配的文件ID封裝為第一報文，以及在接收到所述接收端返回的第二報文后，將要被傳輸的文件封裝成第四報文或者一個或多個第三報文和第四報文，發(fā)送端通信單元，用于將發(fā)送端生成的報文發(fā)送給接收端，以及接收從接收端傳輸的報文，以及在接收端，所述文件傳輸裝置包括文件ID沖突檢查單元，基于所接收的第一報文中包含的文件ID，檢查該文件ID是否與正在傳輸的其它文件的文件ID沖突；接收端報文生成單元，用于在該文件ID不與正在傳輸的其它文件的文件ID沖突時，生成第二報文；以及接收端通 信單元，用于將發(fā)送端生成的報文發(fā)送給接收端，以及接收從接收端傳輸的報文，其中，所述第一報文依次包括報文類型字段、報文子類型字段、文件ID字段、Length字段以及Data字段，所述第二報文依次包括報文類型字段和報文子類型字段，所述第三報文和第四報文依次包括報文類型字段、報文子類型字段、文件ID字段、報文序號字段、Length字段以及Data字段，其中，所述第一到第四報文的報文類型字段被賦予RFB協(xié)議中的同一預留報文號，所述第一到第四報文的報文子類型字段用于記錄被賦予預定定義且為發(fā)送端和接收端已知的第一、第二、第三和第四報文編號，所述第一、第三和第四報文的文件ID字段用于記錄文件ID，所述第三和第四報文的報文序號字段用于記錄文件分塊傳輸時該報文中的文件分塊的序號，所述第一、第三和第四報文的Length字段用于記錄各自的Data字段的長度，所述第一報文的Data字段用于記錄文件名，以及第三和第四報文的Data字段用于記錄數據部分，其中，所述第一報文編號表明該報文是文件傳輸發(fā)起報文，第二報文編號表明該報文是文件傳輸應答報文，第三報文編號表明該報文是非最后一個報文的文件傳輸數據報文，以及第四報文編號表明該報文是作為最后一個報文的文件傳輸數據報文。在上述方面的一個或多個示例中，所述文件傳輸裝置還可以包括文件傳輸中斷單元，位于發(fā)送端和接收端中，用于在文件傳輸過程期間，如果接收到對端發(fā)送的第六報文，則中斷與所述第六報文中包含的文件ID對應的文件的文件傳輸過程，其中，所述第六報文依次包括報文類型字段、報文子類型字段和ID字段，所述第六報文的報文類型字段用于記錄與第二報文中的報文類型相同的報文號，所述報文子類型字段用于記錄預定的第六報文編號，所述第六報文編號表明中斷文件傳輸，以及所述ID字段記錄要被中斷傳輸的文件的ID。根據本發(fā)明的另一方面，提供了一種智能移動終端，包括如上所述的文件傳輸裝置中的發(fā)送端部分、接收端部分或者兩者。根據本發(fā)明的另一方面，提供了一種車載終端，包括如上所述的文件傳輸裝置中的發(fā)送端部分、接收端部分或者兩者。利用上述文件傳輸方法，可以在MirrorLink協(xié)議的基礎上實現智能移動終端和車載終端之間的文件傳輸，增加了該協(xié)議的功能，并提高了用戶體驗。為了實現上述以及相關目的，本發(fā)明的一個或多個方面包括后面將詳細說明并在權利要求中特別指出的特征。下面的說明以及附圖詳細說明了本發(fā)明的某些示例性方面。然而，這些方面指示的僅僅是可使用本發(fā)明的原理的各種方式中的一些方式。此外，本發(fā)明旨在包括所有這些方面以及它們的等同物。


根據下述參照附圖進行的詳細描述，本發(fā)明的上述和其他目的、特征和優(yōu)點將變得更加顯而易見。在附圖中圖1示出了示出了基于MirrorLink協(xié)議在智能移動終端和車載終端之間實現的功能的不意圖；圖2示出了 RFB3. 8協(xié)議中包含的報文類型；圖3示出了 RFB3. 8協(xié)議中被選用來實現雙向文件傳輸的報文號；圖4中示出了被選用的RFB協(xié)議文件傳輸報文的文件傳輸格式；圖5示出了根據本發(fā)明的一個示例的該RFB協(xié)議文件傳輸報文中的預先定義的子類型的編號、對應的文件名稱以及相應說明的圖表；

圖6A示出了圖5中的子類型編號為0的報文的第一示例的報文格式；圖6B示出了圖5中的子類型編號為0的報文的第二示例的報文格式；圖7A示出了圖5中的子類型編號為I的報文的第一示例的報文格式；圖7B示出了圖5中的子類型編號為I的報文的第二示例的報文格式；圖8示出了成功的文件傳輸過程的示意圖；圖9A示出了圖5中的子類型編號為2的報文的第一示例的報文格式；圖9B示出了圖5中的子類型編號為2的報文的第二示例的報文格式；圖10示出了文件傳輸過程中斷的示意圖；圖1lA示出了圖5中的子類型編號為3的報文的第一示例的報文格式；圖1lB示出了圖5中的子類型編號為3的報文的第二示例的報文格式；圖12示出了圖5中的子類型編號為4的報文的報文格式；圖13示出了文件ID協(xié)商成功的報文交互流程示意圖；圖14示出了圖5中的子類型編號為5的報文的報文格式；圖15示出了 rfbFileIDFail報文在文件傳輸過程中的作用及交互流程示意圖；圖16示出了服務端向客戶端傳輸文件時的成功文件傳輸過程的示意圖；圖17示出了用戶拒絕文件傳輸時的示意圖；圖18示出了根據本發(fā)明的第一實施例的用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸方法的流程圖；圖19示出了根據本發(fā)明的第一實施例的用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸裝置的方框示意圖；圖20示出了根據本發(fā)明的第二實施例的用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸方法的流程圖；圖21示出了根據本發(fā)明的第二實施例的用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸裝置的方框示意圖；圖22示出了具有根據本發(fā)明的文件傳輸裝置的智能移動終端的方框示意圖；和圖23示出了具有根據本發(fā)明的文件傳輸裝置的車載終端的方框示意圖。在所有附圖中相同的標號指示相似或相應的特征或功能。
具體實施例方式下面描述本公開的各個方面。應該明白的是，本文的教導可以以多種多樣形式具體體現，并且在本文中公開的任何具體結構、功能或兩者僅僅是代表性的?；诒疚牡慕虒?，本領域技術人員應該明白的是，本文所公開的一個方面可以獨立于任何其它方面實現，并且這些方面中的兩個或多個方面可以按照各種方式組合。例如，可以使用本文所闡述的任何數目的方面，實現裝置或實踐方法。另外，可以使用其它結構、功能、或除了本文所闡述的一個或多個方面之外或不是本文所闡述的一個或多個方面的結構和功能，實現這種裝置或實踐這種方法。此外，本文所描述的任何方面可以包括權利要求的至少一個元素。本發(fā)明通過適當地 擴展MirrorLink協(xié)議的相應部分,基于MirrorLink協(xié)議實現文件傳輸功能，而不影響MirrorLink協(xié)議的現有功能。以下詳細介紹其實現原理。MirrorLink協(xié)議囊括了一系列的協(xié)議,包括UPnP協(xié)議、RTP協(xié)議、RFB協(xié)議等。通過仔細分析可以發(fā)現，在智能移動終端和車載終端之間的數據傳輸中，相比于屏幕顯示數據，聲音數據及用戶控制信號的數據量要小得多。因此，在基于MirrorLink協(xié)議實現的設備互聯(lián)中，傳輸數據量最大、最頻繁的是屏幕顯示內容。這些數據是通過RFB協(xié)議傳輸的。RFB協(xié)議不僅用于傳輸屏幕顯示內容，也用于傳輸用戶輸入等控制信息等。由此可以得出，RFB協(xié)議在建立MirrorLink連接后的整個生命周期中是一直存在的，并且具有能傳輸大量數據的特性，符合文件傳輸的“用戶觸發(fā)、數據量大”的要求?；诖耍x擇擴展RFB協(xié)議來實現文件傳輸功能。RFB (Remote Framebuffer)協(xié)議是一種用于遠程訪問設備圖形界面的協(xié)議。RFB協(xié)議建立在面向連接的協(xié)議之上，如TCP協(xié)議。已發(fā)布的最新版的RFB協(xié)議為3. 8版本，圖2示出了 RFB3. 8協(xié)議中包含的報文類型。從圖2中示出的RFB報文的報文類型可以看出，RFB協(xié)議支持發(fā)送屏幕更新數據、發(fā)送剪切板信息等，該協(xié)議并主要針對屏幕共享的場景，沒有設計文件傳輸功能，故不支持文件傳輸。通常，在處理RFB報文的流程中，在接收到RFB報文后，首先需要讀取RFB報文中的報文號字段(即，報文類型字段)，不同的報文號代表不同的報文類型。例如，當報文號是0時，表示該RFB報文為一個FramebufferUpdate報文，即屏幕更新報文，該報文中的內容為Framebuffer的更新數據。因此，要在RFB協(xié)議的基礎上實現文件傳輸功能，需要注冊文件傳輸特有的報文號?？紤]到要實現雙向文件傳輸，則需要同時在服務端到客戶端(Server->Client)及客戶端到服務端(Client-Server)的報文類型中均注冊相應報文號。為了不與現有的報文號沖突，通常選擇RFB協(xié)議中的預留報文號。此外，為了不占用RFB協(xié)議的小協(xié)議號的未來發(fā)展空間，優(yōu)選地，選用圖3所示的報文號(即，248)。在本發(fā)明的其它示例中，也可以選用RFB協(xié)議中的其它預留報文號。在如上選定報文號后，在接收RFB報文的處理流程中，若讀取的報文號類型為248，則表明該RFB報文是文件傳輸報文，后續(xù)的流程需要調用文件傳輸的處理流程進行處理。同樣，若要將文件數據封裝在RFB報文中進行發(fā)送，也需要將該RFB報文的報文類型字段(即，報文號)設置為248。在確定報文號后，需要定義RFB協(xié)議文件傳輸報文的文件傳輸格式，圖4不出了所定義的文件傳輸格式。如圖4所示，在報文號選定為248的情況下，Sbits (即，I個字節(jié))的Type字段需要設置為如前所述的報文號248,表不該RFB報文是文件傳輸報文。8bits的Subtype字段用于進一步表明該RFB報文的具體類型。不同的Subtype表明了報文的不同功能，包括傳輸文件數據、終止傳輸、協(xié)商文件ID等。圖5示出了具體的Subtype值以及其對應的報文功能，該具體的Subtype值預先由發(fā)送端和接收端協(xié)商確定。這里要說明的是，圖4中示出的僅僅是示例，每個字段的長度還可以采用其它合適的值。例如，Subtype字段的長度可以為至少為2比特的任意長度。此外，Subtype值與各個報文功能之間的對應關系也可以采用其它形式對應，并且Subtype值也可以采用其它合適值。為了實現文件傳輸報文的正常傳輸，注冊了六種文件報文子類型，其對應的Subtype值如圖5所示。

當Subtype為0時，表明該報文為一個普通文件傳輸報文(即，本發(fā)明中的第三報文)，具體的報文格式如圖6A和圖6B所示。圖6A示出了圖5中的子類型編號為0的報文在不選用文件ID進行文件傳輸的示例下(在下文中稱為第一示例)的報文格式；圖6B示出了圖5中的子類型編號為0的報文在選用文件ID進行文件傳輸的示例中(在下文中稱為第二示例)的報文格式。在圖6A中，Sequence字段(即，報文序號字段)為文件分塊傳輸時該報文的序號，其長度為2個字節(jié)。其中，首個文件分塊的序號為0，后續(xù)分塊序號值依次遞增。Length字段指明Data字段的長度，并且所記錄的Data字段長度的單位為字節(jié)，該Length字段的長度為4個字節(jié)。Data字段為數據部分，長度由Length指定。在圖6B中，Id字段為文件id，其長度為2個字節(jié)(S卩，16比特)。不同的id號標識不同的文件，同一個文件分塊進行傳輸時，具有相同的id號。Sequence字段(即,報文序號字段)為文件分塊傳輸時該報文的序號，其長度為2個字節(jié)。其中，首個文件分塊的序號為0，后續(xù)分塊序號值依次遞增。Length字段指明Data字段的長度，并且所記錄的Data字段長度的單位為字節(jié)，該Length字段的長度為4個字節(jié)。Data字段為數據部分，長度由Length指定。當Subtype為I時，表明該報文為文件傳輸過程的最后一個報文(即，本發(fā)明中的第四報文)，具體的報文格式如圖7A和圖7B所示。圖7A示出了圖5中的子類型編號為I的報文在第一示例中的報文格式；圖7B示出了圖5中的子類型編號為I的報文在第二示例中的報文格式。
在圖7A中，Sequence字段為文件分塊傳輸時該報文的序號,其長度為2個字節(jié)。若該報文既是最后一個報文(最后一個文件分塊)也是第一個文件分塊，則序號為O。否則，是前一文件分塊的序號加I。例如，如果緊接著該報文的上一普通文件傳輸報文的序號為3，則該報文的序號為4。Length字段指明Data字段的長度，其長度為4個字節(jié)，并且所記錄的Data字段長度的單位為字節(jié)。Data字段為數據部分，長度由Length字段指定。在圖7B中，Id字段為文件id，其長度為2個字節(jié)(S卩，16比特)。不同的id號標識不同的文件，同一個文件分塊進行傳輸時，具有相同的id號。Sequence字段為文件分塊傳輸時該報文的序號，其長度為2個字節(jié)。若該報文既是最后一個報文(最后一個文件分塊)也是第一個文件分塊，則序號為O。否則，是前一文件分塊的序號加I。例如，如果緊接著該報文的上一普通文件傳輸報文的序號為3，則該報文的序號為4。Length字段指明Data字段的長度，其長度為4個字節(jié)，并且所記錄的Data字段長度的單位為字節(jié)。Data字段為數據部分，長度由Length字段指定。一次成功的文件傳輸過程，如圖8所示。文件發(fā)送方發(fā)送rfbFilePacket，報文中攜帶文件數據。最后一個文件分塊封裝在rfbEndOfFile報文中。文件傳輸過程除了可以在文件傳輸完成后正常結束，也可以由用戶輸入等其他方式異常終止。發(fā)生異常時，不管是文件接收方還是文件發(fā)送方，均需要將異常通知到對方，即，通知對方中斷文件傳輸。因此需要一種能用于通知對方中斷文件傳輸的報文。為此，將Subtype=2的報文設計為中斷文件傳輸報文。當Subtype=2時，表明該報文是文件傳輸中斷報文(即，本發(fā)明中的第六報文)，該類報文用于文件傳輸的一方通知另一方中斷文件傳輸，并進行相應的清理工作。具體的報文格式如圖9A和圖9B所示。圖9A示出了圖5中的子類型編號為2的報文在第一示例中的報文格式；圖9B示出了圖5中的子類型編號為2的報文在第二示例中的報文格式。在圖9B中，Id字段為文件id，表明需要中斷傳輸的文件的文件id。Id字段的長度為2個字節(jié)。文件傳輸中 斷報文可以由文件傳輸雙方中任何一方(發(fā)送端或接收端)發(fā)起，并且可以在文件傳輸過程中的任意時刻發(fā)起。一旦接收到文件傳輸中斷報文，發(fā)送端將終止文件發(fā)送或者終止具有相應文件id的文件的發(fā)送；接收端將丟棄已經接收的文件數據或者丟棄已經接收的相應文件id的文件數據，終止文件傳輸。文件傳輸過程中斷的示意圖如圖10所示。上述3種報文可以保證文件傳輸過程的順利進行。但啟動文件傳輸過程需要一系列流程，涉及到請求文件傳輸、協(xié)商所傳輸的文件ID等。因此還需要設計用于啟動文件傳輸過程的報文格式。如圖5所示，與啟動文件傳輸過程相關的報文類型主要有三種文件傳輸發(fā)起報文、文件傳輸應答報文以及文件傳輸拒絕報文。當Subtype=3時，表明該報文為整個文件傳輸過程的第一個報文(即，本發(fā)明中的第一報文)，其中攜帶了文件名，或者攜帶有文件名和ID，具體的報文格式如圖1lA和圖1lB所不。該報文用于文件傳輸協(xié)商。圖1lA示出了圖5中的子類型編號為3的報文在第一示例中的報文格式。如圖1lA所示，Length字段指明Data字段的長度，即文件名的長度，單位為字節(jié)。Length字段的長度為4個字節(jié)。Data字段記錄文件名，其長度由Length字段指定。在這種情況下，發(fā)送端按照該格式將文件名封裝成第一報文后發(fā)送到接收端，然后根據接收端的回復報文決定是否進行文件傳輸。圖1lB示出了圖5中的子類型編號為3的報文在第二示例中的報文格式。如圖1lB所示，Id字段為文件id，其長度為2個字節(jié)。通常，該文件id可以由用戶任意選擇。Length字段指明Data字段的長度，即文件名的長度，單位為字節(jié)。Length字段的長度為4個字節(jié)。Data字段記錄文件名，其長度由Length字段指定。在這種情況下,發(fā)送端首先選擇文件id，并按照該格式，將文件名和文件id封裝成第一報文后發(fā)送到接收端，然后根據接收端的回復報文決定是否采用該文件id進行文件傳輸。在第二示例中，第一報文傳輸即將發(fā)送的文件的文件名，并根據文件名選擇文件ID。文件ID的選擇沒有特殊要求，但必須不能與正在傳輸的其他文件的文件ID沖突。該報文表明即將發(fā)起文件傳輸，接收方接收到該報文后可以檢查該文件ID是否與正在傳輸的其它文件的文件ID沖突，并且根據是否沖突，返回不同的回復報文。當Subtype=4時，表明該報文為文件傳輸應答報文，即確認可以進行文件傳輸的報文(即，本發(fā)明中的第二報文)。在第一示例和第二示例中，具體報文格式如圖12所示。在第一示例(即，不采用文件ID進行傳輸的示例)中，該報文表示文件接收端同意進行文件傳輸，在第二示例(即，采用文件ID進行文件傳輸的示例)中，該報文表示同意選擇先前發(fā)送的文件ID進行文件傳輸。即所選的文件ID沒有和接收端正在傳輸的其他文件的ID沖突，可以采用該文件ID進行文件傳輸。在第二示例中，用戶同意進行文件傳輸，并且文件ID協(xié)商成功的報文交互流程如圖13所示。文件ID協(xié)商成功的準則是接收端檢查該文件ID是否和正在傳輸的其他文件的ID是否沖突，不沖突則返回rfbFilelDOK。此外，在第二示例中，在接收到該報文后，除了進行文件ID沖突檢查之外，在接收端還可以由用戶確認是否進行文件傳輸，并根據用戶的確認結果返回不同的回復報文。通常，用戶的確認結果的優(yōu)先級被設置為大于文件ID沖突檢查結果。即，無論文件ID沖突結果如何，只要用戶確認不進行文件傳輸，就返回表明文件ID協(xié)商失敗的回復報文。換言之，只有在用戶確認進行文件傳輸并且文件ID沖突檢查結果為不沖突時，才返回表明 文件ID協(xié)商成功的回復報文。當Subtype=5時，表明該報文為文件傳輸拒絕報文(S卩，本發(fā)明中的第五報文)。在第一示例和第二示例中，具體報文格式如圖14所示。在第一示例中，該報文表示接收端不同意進行文件傳輸。在第二示例中，該報文表示接收端不同意先前選擇的文件ID，即通知發(fā)送端重新選擇新的文件ID。換言之，該報文表明先前選擇的文件ID和接收端其他正在傳輸的文件ID發(fā)生沖突，需要發(fā)送端重新選擇文件ID。rfbFileIDFail報文在文件傳輸過程中的作用及交互流程如圖15所示?？梢姡搱笪挠糜谕ㄖl(fā)送方重新選擇文件ID。通常情況下，某一時刻只能有少量的文件在同時傳輸，大部分情況只有一個文件在進行傳輸。因此，這種簡單的交互方式足以滿足文件ID的協(xié)商。如上定義了 6種不同的Subtype類型,該6種Subtype類型可以滿足文件傳輸過程中的文件傳輸發(fā)起、文件傳輸應答、文件傳輸拒絕、文件傳輸、文件傳輸正常終止或異常終止等功能。此外，上面的描述僅僅是示例。在本發(fā)明的其它示例中，Length字段、Id字段和Sequence字段的長度可以采用其它合適值。文件傳輸是雙向的，服務端(智能移動電話)和客戶端(車載終端)都可以申請開始文件傳輸。文件傳輸由用戶操作觸發(fā)，文件傳輸過程將占用大量帶寬，并且可能是一個漫長的過程，因此，即使文件傳輸由用戶操作觸發(fā)，真正的文件傳輸也需要由用戶確認。以服務端向客戶端傳輸文件為例，一次成功的文件傳輸過程如圖16所示。當用戶拒絕文件傳輸時，文件傳輸過程如圖17所示。如上描述了擴展的RFB協(xié)議中的用于文件傳輸的報文的定義以及具體的報文格式。下面將參照附圖對本發(fā)明的實施例進行描述。(第一實施例)圖18描述根據本發(fā)明的第一實施例的用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸方法的流程圖。這里，第一實施例中的第一到第六報文的定義對應于上述第一不例中的報文格式定義。所述文件傳輸方法是在發(fā)送端和接收端之間執(zhí)行，這里，智能移動終端和車載終端中的任何一個可以作為發(fā)送端，以及所述智能終端和車載終端中的另一個作為接收端。

如圖18所示，在步驟S1810，在接收到文件傳輸請求后，發(fā)送端將要被傳輸的文件的文件名封裝為第一報文，并且在步驟S1820，作為文件傳輸過程的第一個報文發(fā)送給接收端。在接收到第一報文后，在步驟S1830，接收端基于所接收的第一報文，確認是否同意進行文件傳輸。如果同意，則在步驟S1840，接收端生成第二報文，然后在步驟S1850，將所生成的第二報文返回給發(fā)送端。如果不同意，則接收端生成第五報文，并返回給發(fā)送端。如果發(fā)送端接收到所述接收端返回的第五報文，則終止文件傳輸。在接收到所述接收端返回的第二報文后，在步驟S1860，發(fā)送端將要被傳輸的文件封裝成第四報文或者一個或多個第三報文和第四報文，并且在步驟S1870，將所生成的第四報文或者一個或多個第三報文和第四報文傳輸給所述接收端。這里要說明的是，如果要傳輸的文件僅僅包括一個文件分塊(即，將要傳輸的文件作為完整文件傳輸)時，則僅僅生成一個第四報文，如果包括多個文件分塊，則生成一個或多個第三報文以及一個第四報文。在步驟S1880，接收端接收發(fā)送端所傳輸的報文，如果接收到第三報文，則繼續(xù)接收，如果接收端接收到第四報文，則停止接收并且結束文件傳輸過程。上述僅僅是本發(fā)明的一個例示性示例，還可以對上述示例進行各種修改。例如，上述文件傳輸方法還可以包括在文件傳輸過程期間(文件傳輸過程中的任意時刻)，如果接收端或者發(fā)送端接收到對端發(fā)送的第六報文，則中斷文件傳輸過程。圖19示出了根據本發(fā)明的用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸裝置1900的方框示意圖。如圖19所示，在發(fā)送端，文件傳輸裝置1900包括發(fā)送端報文生成單元1910和發(fā)送端通信單元1920。發(fā)送端報文生成單元1920用于在接收到文件傳輸請求后，將要被傳輸的文件的文件名封裝為第一報文，以及在接收到所述接收端返回的第二報文后，將要被傳輸的文件封裝成第四報文或者一個或多個第三報文和第四報文。發(fā)送端通信單元1920用于將發(fā)送端生成的報文發(fā)送給接收端，以及接收從接收端傳輸的報文。從接收端接收的報文包括第二報文和第五報文。當從接收端接收的報文是第五報文時，終止文件傳輸。
在接收端，所述文件傳輸裝置包括接收端通信單元1930、文件傳輸確認單元1940和接收端報文生成單元1950。接收端通信單元1930用于將發(fā)送端生成的報文發(fā)送給接收端，以及接收從接收端傳輸的報文。文件傳輸確認單元1940基于所接收的第一報文中，確認是否進行文件傳輸。接收端報文生成單元1950用于在確認進行文件傳輸時，生成第二報文。此外，接收端報文生成單兀1950還用于在確認不進行文件傳輸時,生成第五報文。此外，優(yōu)選地，文件傳輸裝置1900還可以包括文件傳輸中斷單元(未示出)，用于在文件傳輸過程期間，如果接收到對端發(fā)送的第六報文，則中斷文件傳輸過程。所述文件傳輸中斷單元可以位于發(fā)送端和接收端中。(第二實施例)圖20描述根據本發(fā)明的第二實施例的用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸方法的流程圖。這里，第二實施例中的第一到第六報文的定義對應于上述第二示例中的報文格式定義。所述文件傳輸方法是在發(fā)送端和接收端之間執(zhí)行，這里，智能移動終端和車載終端中的任何一個可以作為發(fā)送端，以及所述智能終端和車載終端中的另一個作為接收端。如圖20所示，在步驟S2010，在接收到文件傳輸請求后，發(fā)送端為要被傳輸的文件分配文件ID (S卩，選擇文件ID)。接著，在步驟S2020，發(fā)送端將要被傳輸的文件的文件名和所分配的文件ID封裝為第一報文，并且在步驟S2030，作為文件傳輸過程的第一個報文發(fā)送給接收端。在接收到第一報文后，在步驟S2040，接收端基于所接收的第一報文中包含的文件ID，檢查該文件ID是否與正在傳輸的其它文件的文件ID沖突。如果不沖突，則在步驟S2050，接收端生成第二報文，然后在步驟S2060，將所生成的第二報文返回給發(fā)送端。如果沖突，則生成第五報文，并返回給發(fā)送端，流程返回到步驟S2010。如果發(fā)送端接收到所述接收端返回的第五報文，則重新為要被傳輸的文件分配新文件ID，并且基于重新分配的新文件ID和文件名封裝成新的第一報文發(fā)送給所述接收端繼續(xù)進行文件ID沖突檢查，如此循環(huán)，直到不發(fā)生沖突為止。在接收到所述接收端返回的第二報文后，在步驟S2070，發(fā)送端將要被傳輸的文件封裝成第四報文或者一個或多個第三報文和第四報文，并且在步驟S2080，將所生成的第四報文或者一個或多個第三報文和第四報文傳輸給所述接收端。這里要說明的是，如果要傳輸的文件僅僅包括一個文件分塊時，則僅僅生成一個第四報文，如果包括多個文件分塊，則生成一個或多個第三報文以及一個第四報文。在步驟S2090，接收端接收發(fā)送端所傳輸的報文，如果接收到第三報文，則繼續(xù)接收，如果接收端接收到第四報文，則停止接收并且結束文件傳輸過程。上述僅僅是本發(fā)明的一個例示性示例，還可以對上述示例進行各種修改。例如，上述文件傳輸方法還可以包括在文件傳輸過程期間(文件傳輸過程中的任意時刻)，如果接收端或者發(fā)送端接收到對端發(fā)送的第六報文，則中斷與所述第六報文中包含的文件ID對應的文件的文件傳輸過程。

圖21示出了根據本發(fā)明的用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸裝置2100的方框示意圖。
如圖21所示，在發(fā)送端，文件傳輸裝置2100包括文件ID分配單元2110、發(fā)送端報文生成單元2120和發(fā)送端通信單元2130。所述文件ID分配單元2110用于在接收到文件傳輸請求后，為要被傳輸的文件分配文件ID。發(fā)送端報文生成單元2120用于將要被傳輸的文件的文件名和所分配的文件ID封裝為第一報文，以及在接收到所述接收端返回的第二報文后，將要被傳輸的文件封裝成第四報文或者一個或多個第三報文和第四報文。發(fā)送端通信單元2130用于將發(fā)送端生成的報文發(fā)送給接收端，以及接收從接收端傳輸的報文。從接收端接收的報文包括第二報文和第五報文。當從接收端接收的報文是第五報文時，文件ID分配單元2110重新為要被傳輸的文件分配新文件ID，并且發(fā)送端報文處理單元2120基于重新分配的新文件ID和文件名封裝成新的第一報文發(fā)送給所述接收端。在接收端，所述文件傳輸裝置包括接收端通信單元2140、文件ID檢查單元2150和接收端報文生成單元2160。接收端通信單元2140用于將發(fā)送端生成的報文發(fā)送給接收端，以及接收從接收端傳輸的報文。文件ID沖突檢查單元2150基于所接收的第一報文中包含的文件ID，檢查該文件ID是否與正在傳輸的其它文件的文件ID沖突。接收端報文生成單元2160用于在該文件ID不與正在傳輸的其它文件的文件ID沖突時，生成第二報文。此外，接收端報文生成單兀2160還用于在該文件ID與正在傳輸的其它文件的文件ID沖突時，生成第五報文。優(yōu)選地，在需要用戶進行確認的情況下，只有在用戶確認進行文件傳輸并且該文件ID不與正在傳輸的其它文件的文件ID沖突時，生成第二報文；否則，生成第五報文。此外，優(yōu)選地，文件傳輸裝置2100還可以包括文件傳輸中斷單元(未示出)，用于在文件傳輸過程期間，如果接收 到對端發(fā)送的第六報文，則中斷與所述第六報文中包含的文件ID對應的文件的文件傳輸過程。所述文件傳輸中斷單元可以位于發(fā)送端和接收端中。圖22示出了具有根據本發(fā)明的文件傳輸裝置的智能移動終端10的方框示意圖。如圖22所示，智能移動終端10包括上述文件傳輸裝置1900或2100中的發(fā)送端部分、接收端部分或者兩者。圖23示出了具有根據本發(fā)明的文件傳輸裝置的車載終端20的方框示意圖。如圖23所示，車載終端20包括上述文件傳輸裝置1900或2100中的發(fā)送端部分、接收端部分或
者兩者。利用上述基用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸方法及裝置，可以在MirrorLink協(xié)議的基礎上實現智能移動終端和車載終端之間的文件傳輸，由此提聞了用戶體驗。此外，根據本發(fā)明的方法還可以被實現為由CPU執(zhí)行的計算機程序。在該計算機程序被CPU執(zhí)行時，執(zhí)行本發(fā)明的方法中限定的上述功能。此外，上述方法步驟以及系統(tǒng)單元也可以利用控制器以及用于存儲使得控制器實現上述步驟或單元功能的計算機程序的計算機可讀存儲設備實現。例如，根據本發(fā)明的移動終端可以被實現為一個或多個處理器，以及與該一個或多個處理器相連的存儲器，該存儲器中存儲具有可以使得處理器執(zhí)行本發(fā)明的方法中所限定的各個步驟的指令的計算機程序。盡管前面公開的內容示出了本發(fā)明的示例性實施例，但是應當注意，在不背離權利要求限定的本發(fā)明的范圍的前提下，可以進行多種改變和修改。根據這里描述的發(fā)明實施例的方法權利要求的功能、步驟和/或動作不需以任何特定順序執(zhí)行。此外，盡管本發(fā)明的元素可以以個體形式描述或要求，但是也可以設想多個，除非明確限制為單數。雖然如上參照圖描述了根據本發(fā)明的各個實施例進行了描述，但是本領域技術人員應當理解，對上述本 發(fā)明所提出的各個實施例，還可以在不脫離本發(fā)明內容的基礎上做出各種改進。因此，本發(fā)明的保護范圍應當由所附的權利要求書的內容確定。
權利要求
1.一種用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸方法，其中，所述智能移動終端和車載終端中之一作為發(fā)送端，以及所述智能終端和車載終端中的另一個作為接收端，所述方法包括 在接收到文件傳輸請求后，發(fā)送端將要被傳輸的文件的文件名封裝為第一報文，并作為文件傳輸過程的第一個報文發(fā)送給接收端； 接收端基于所接收的第一報文，確認是否進行文件傳輸，如進行文件傳輸，則向發(fā)送端返回第二報文； 在接收到返回的第二報文后，發(fā)送端將要被傳輸的文件封裝成第四報文或者一個或多個第三報文和第四報文，傳輸給所述接收端， 其中，所述第一報文依次包括報文類型字段、報文子類型字段、Length字段以及Data字段，所述第二報文依次包括報文類型字段和報文子類型字段，所述第三報文和第四報文依次包括報文類型字段、報文子類型字段、報文序號字段、Length字段以及Data字段， 其中，所述第一到第四報文的報文類型字段被賦予RFB協(xié)議中的同一預留報文號，所述第一到第四報文的報文子類型字段用于記錄被賦予預定定義且為發(fā)送端和接收端已知的第一、第二、第三和第四報文編號，所述第三和第四報文的報文序號字段用于記錄文件分塊傳輸時該報文中的文件分塊的序號，所述第一、第三和第四報文的Length字段用于記錄各自的Data字段的長度，所述第一報文的Data字段用于記錄文件名，以及第三和第四報文的Data字段用于記錄數據部分， 其中，所述第一報文編號表明該報文是文件傳輸發(fā)起報文，第二報文編號表明該報文是文件傳輸應答報文，第三報文編號表明該報文是非最后一個報文的文件傳輸數據報文，以及第四報文編號表明該報文是作為最后一個報文的文件傳輸數據報文。
2.如權利要求1所述的文件傳輸方法，其中，在將所述第一報文發(fā)送給接收端后，如果接收到所述接收端返回的第五報文，則發(fā)送端不進行文件傳輸， 其中，所述第五報文依次包括報文類型字段和報文子類型字段，所述第五報文的報文類型字段用于記錄與第二報文中的報文類型相同的報文號，所述報文子類型字段用于記錄預定的第五報文編號，所述第五報文編號表明不進行文件傳輸。
3.如權利要求1所述的文件傳輸方法，還包括 在文件傳輸過程期間，如果接收端或者發(fā)送端接收到對端發(fā)送的第六報文，則中斷文件傳輸過程， 其中，所述第六報文依次包括報文類型字段和報文子類型字段，所述第六報文的報文類型字段用于記錄與第二報文中的報文類型相同的報文號，以及所述報文子類型字段用于記錄預定的第六報文編號，所述第六報文編號表明中斷文件傳輸。
4.一種用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸方法，其中，所述智能移動終端和車載終端中之一作為發(fā)送端，以及所述智能終端和車載終端中的另一個作為接收端，所述方法包括 在接收到文件傳輸請求后，發(fā)送端為要被傳輸的文件分配文件ID ； 發(fā)送端將要被傳輸的文件的文件名和所分配的文件ID封裝為第一報文，并作為文件傳輸過程的第一個報文發(fā)送給接收端； 接收端基于所接收的第一報文中包含的文件ID，檢查該文件ID是否與正在傳輸的其它文件的文件ID沖突，在檢查出沒有沖突時，向發(fā)送端返回第二報文；以及 在接收到所述接收端返回的第二報文后，發(fā)送端將要被傳輸的文件封裝成第四報文或者一個或多個第三報文和第四報文，傳輸給所述接收端， 其中，所述第一報文依次包括報文類型字段、報文子類型字段、文件ID字段、Length字段以及Data字段，所述第二報文依次包括報文類型字段和報文子類型字段，所述第三報文和第四報文依次包括報文類型字段、報文子類型字段、文件ID字段、報文序號字段、Length字段以及Data字段， 其中，所述第一到第四報文的報文類型字段被賦予RFB協(xié)議中的同一預留報文號，所述第一到第四報文的報文子類型字段用于記錄被賦予預定定義且為發(fā)送端和接收端已知的第一、第二、第三和第四報文編號，所述第一、第三和第四報文的文件ID字段用于記錄文件ID，所述第三和第四報文的報文序號字段用于記錄文件分塊傳輸時該報文中的文件分塊的序號，所述第一、第三和第四報文的Length字段用于記錄各自的Data字段的長度，所述第一報文的Data字段用于記錄文件名，以及第三和第四報文的Data字段用于記錄數據部分， 其中，所述第一報文編號表明該報文是文件傳輸發(fā)起報文，第二報文編號表明該報文是文件傳輸應答報文，第三報文編號表明該報文是非最后一個報文的文件傳輸數據報文，以及第四報文編號表明該報文是作為最后一個報文的文件傳輸數據報文。
5.如權利要求4所述的文件傳輸方法，其中，在將所述第一報文發(fā)送給接收端后，如果接收到所述接收端返回的第五報文，則發(fā)送端重新為要被傳輸的文件分配新文件ID，并且基于重新分配的新文件ID和文件名封裝成新的第一報文發(fā)送給所述接收端， 其中，所述第五報文依次包括報文類型字段和報文子類型字段，所述第五報文的報文類型字段用于記錄與第二報文中的報文類型相同的報文號，所述報文子類型字段用于記錄預定的第五報文編號，所述第五報文編號表明所分配的文件ID與正在傳輸的其它文件的文件ID沖突。
6.如權利要求4所述的文件傳輸方法，還包括 在文件傳輸過程期間，如果接收端或者發(fā)送端接收到對端發(fā)送的第六報文，則中斷與所述第六報文中包含的文件ID對應的文件的文件傳輸過程， 其中，所述第六報文依次包括報文類型字段、報文子類型字段和ID字段，所述第六報文的報文類型字段用于記錄與第二報文中的報文類型相同的報文號，所述報文子類型字段用于記錄預定的第六報文編號，所述第六報文編號表明中斷文件傳輸，以及所述ID字段記錄要被中斷傳輸的文件的ID。
7.一種用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸裝置，其中，所述智能移動終端和車載終端中之一作為發(fā)送端，以及所述智能終端和車載終端中的另一個作為接收端，所述文件傳輸裝置包括 在發(fā)送端，所述文件傳輸裝置包括 發(fā)送端報文生成單元，用于在接收到文件傳輸請求后，將要被傳輸的文件的文件名封裝為第一報文，以及在接收到所述接收端返回的第二報文后，將要被傳輸的文件封裝成第四報文或者一個或多個第三報文和第四報文； 發(fā)送端通信單元，用于將發(fā)送端生成的報文發(fā)送給接收端，以及接收從接收端傳輸的報文， 在接收端，所述文件傳輸裝置包括 文件傳輸確認單元，用于基于所接收的第一報文，確認是否進行文件傳輸； 接收端報文生成單元，用于在確認進行文件傳輸時，生成第二報文；以及接收端通信單元，用于將發(fā)送端生成的報文發(fā)送給接收端，以及接收從接收端傳輸的報文， 其中，所述第一報文依次包括報文類型字段、報文子類型字段、Length字段以及Data字段，所述第二報文依次包括報文類型字段和報文子類型字段，所述第三報文和第四報文依次包括報文類型字段、報文子類型字段、報文序號字段、Length字段以及Data字段， 其中，所述第一到第四報文的報文類型字段被賦予RFB協(xié)議中的同一預留報文號，所述第一到第四報文的報文子類型字段用于記錄被賦予預定定義且為發(fā)送端和接收端已知的第一、第二、第三和第四報文編號，所述第三和第四報文的報文序號字段用于記錄文件分塊傳輸時該報文中的文件分塊的序號，所述第一、第三和第四報文的Length字段用于記錄各自的Data字段的長度，所述第一報文的Data字段用于記錄文件名，以及第三和第四報文的Data字段用于記錄數據部分， 其中，所述第一報文編號表明該報文是文件傳輸發(fā)起報文，第二報文編號表明該報文是文件傳輸應答報文，第三報文編號表明該報文是非最后一個報文的文件傳輸數據報文，以及第四報文編號表明該報文是作為最后一個報文的文件傳輸數據報文。
8.如權利要求7所述的文件傳輸裝置，還包括 文件傳輸中斷單元，位于發(fā)送端和接收端中，用于在文件傳輸過程期間，如果接收到對端發(fā)送的第六報文，則中斷文件傳輸過程， 其中，所述第六報文依次包括報文類型字段和報文子類型字段，所述第六報文的報文類型字段用于記錄與第二報文中的報文類型相同的報文號，所述報文子類型字段用于記錄預定的第六報文編號，所述第六報文編號表明中斷文件傳輸。
9.一種用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸裝置，其中，所述智能移動終端和車載終端中之一作為發(fā)送端，以及所述智能終端和車載終端中的另一個作為接收端，所述文件傳輸裝置包括 在發(fā)送端，所述文件傳輸裝置包括 文件ID分配單元，用于在接收到文件傳輸請求后，為要被傳輸的文件分配文件ID ；發(fā)送端報文生成單元，用于將要被傳輸的文件的文件名和所分配的文件ID封裝為第一報文，以及在接收到所述接收端返回的第二報文后，將要被傳輸的文件封裝成第四報文或者一個或多個第三報文和第四報文， 發(fā)送端通信單元，用于將發(fā)送端生成的報文發(fā)送給接收端，以及接收從接收端傳輸的報文，以及在接收端，所述文件傳輸裝置包括 文件ID沖突檢查單元，用于基于所接收的第一報文中包含的文件ID，檢查該文件ID是否與正在傳輸的其它文件的文件ID沖突； 接收端報文生成單元，用于在該文件ID不與正在傳輸的其它文件的文件ID沖突時，生成第二報文；以及 接收端通信單元，用于將發(fā)送端生成的報文發(fā)送給接收端，以及接收從接收端傳輸的報文， 其中，所述第一報文依次包括報文類型字段、報文子類型字段、文件ID字段、Length字段以及Data字段，所述第二報文依次包括報文類型字段和報文子類型字段，所述第三報文和第四報文依次包括報文類型字段、報文子類型字段、文件ID字段、報文序號字段、Length字段以及Data字段， 其中，所述第一到第四報文的報文類型字段被賦予RFB協(xié)議中的同一預留報文號，所述第一到第四報文的報文子類型字段用于記錄被賦予預定定義且為發(fā)送端和接收端已知的第一、第二、第三和第四報文編號，所述第一、第三和第四報文的文件ID字段用于記錄文件ID，所述第三和第四報文的報文序號字段用于記錄文件分塊傳輸時該報文中的文件分塊的序號，所述第一、第三和第四報文的Length字段用于記錄各自的Data字段的長度，所述第一報文的Data字段用于記錄文件名，以及第三和第四報文的Data字段用于記錄數據部分， 其中，所述第一報文編號表明該報文是文件傳輸發(fā)起報文，第二報文編號表明該報文是文件傳輸應答報文，第三報文編號表明該報文是非最后一個報文的文件傳輸數據報文，以及第四報文編號表明該報文是作為最后一個報文的文件傳輸數據報文。
10.如權利要求9所述的文件傳輸裝置，還包括 文件傳輸中斷單元，位于發(fā)送端和接收端中，用于在文件傳輸過程期間，如果接收到對端發(fā)送的第六報文，則中斷與所述第六報文中包含的文件ID對應的文件的文件傳輸過程， 其中，所述第六報文依次包括報文類型字段、報文子類型字段和ID字段，所述第六報文的報文類型字段用于記錄與第二報文中的報文類型相同的報文號，所述報文子類型字段用于記錄預定的第六報文編號，所述第六報文編號表明中斷文件傳輸，以及所述ID字段記錄要被中斷傳輸的文件的ID。
11.一種智能移動終端，包括如權利要求7-10中任何一個所述的文件傳輸裝置中的發(fā)送端部分、接收端部分或者兩者。
12.—種車載終端,包括如權利要求7-10中任何一個所述的文件傳輸裝置中的發(fā)送端部分、接收端部分或者兩者。
全文摘要
本發(fā)明提供了一種用于在智能移動終端和車載終端之間進行文件傳輸的文件傳輸方法，包括在接收到文件傳輸請求后，發(fā)送端將要被傳輸的文件的文件名封裝為第一報文，并作為文件傳輸過程的第一個報文發(fā)送給接收端；接收端基于所接收的第一報文，確認是否進行文件傳輸，如進行文件傳輸，則向發(fā)送端返回第二報文；在接收到返回的第二報文后，發(fā)送端將要被傳輸的文件封裝成第四報文或者一個或多個第三報文和第四報文，傳輸給所述接收端。利用該方法，可以在MirrorLink協(xié)議的基礎上實現智能移動終端和車載終端之間的文件傳輸，增加了協(xié)議的功能，提高了用戶體驗。
文檔編號H04L29/08GK103067462SQ20121055454
公開日2013年4月24日 申請日期2012年12月19日 優(yōu)先權日2012年12月19日
發(fā)明者聶山人, 張騫, 楊明, 張翼, 馬晟 申請人:東軟集團股份有限公司