一種基于udp協(xié)議實現(xiàn)智能車載終端的接入方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明屬于計算機網(wǎng)絡(luò)數(shù)據(jù)通信技術(shù)領(lǐng)域，涉及一種智能車載終端的接入技術(shù)，尤其是一種基于UDP協(xié)議實現(xiàn)智能車載終端的接入方法。
【背景技術(shù)】
[0002]隨著移動互聯(lián)網(wǎng)、車聯(lián)網(wǎng)及物聯(lián)網(wǎng)的發(fā)展，通過配備車載LTE-Fi產(chǎn)品的城市公交、長途客運車、長途貨車、出租車、小型面包車、地鐵、游輪等移動交通工具搖身一變成為一個移動網(wǎng)絡(luò)，從而讓用戶享受到無處不在的信息服務(wù)；
[0003]而現(xiàn)有的網(wǎng)絡(luò)傳輸協(xié)議有兩種形式，面向連接的服務(wù)(TCP)和無連接的服務(wù)(UDP)。TCP(Transmiss1nControI Protocol，傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的運輸層通信協(xié)議。UDP(User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議)是一種面向事務(wù)的、無連接的簡單信息傳送服務(wù)。
[0004]傳統(tǒng)的智能車載終端與服務(wù)器之間采用TCP通訊，基于TCP協(xié)議的通信在傳遞數(shù)據(jù)之前，要先建立連接，而且在數(shù)據(jù)傳遞時的確認(rèn)機制、重傳機制、擁塞控制機制等都會消耗大量的時間，并且需要在每臺設(shè)備上維護所有的傳輸連接，如果智能車載終端數(shù)量居多，就會大大降低網(wǎng)絡(luò)的傳輸效率，繼而造成丟包、時延等現(xiàn)象的出現(xiàn)，直接影響智能車載終端運行。

【發(fā)明內(nèi)容】

[0005]本發(fā)明的目的在于克服上述現(xiàn)有技術(shù)的缺點，提供一種基于UDP協(xié)議實現(xiàn)智能車載終端的接入方法。
[0006]本發(fā)明的目的是通過以下技術(shù)方案來實現(xiàn)的:
[0007]這種基于UDP協(xié)議實現(xiàn)智能車載終端的接入方法，服務(wù)器接收到智能車載終端請求的報文消息后通過套接字API獲取報文的端口號和IP信息，利用套接字API創(chuàng)建客戶端，每臺智能車載終端對應(yīng)一個套接字客戶端，套接字客戶端用于向智能車載終端回傳響應(yīng)的數(shù)據(jù)報文;采取套接字緩存機制對請求的大容量并發(fā)數(shù)據(jù)包進行處理，待服務(wù)器按照報文格式處理結(jié)束后對智能車載終端進行響應(yīng)。
[0008]上述套接字緩存機制是指套接字將創(chuàng)建相應(yīng)的套接字緩存，并將智能車載終端的報文消息拷貝到緩存中，當(dāng)報文消息在各協(xié)議層傳輸?shù)倪^程中，將報文頭插入到智能車載終端數(shù)據(jù)之前，套接字緩存為報文頭申請足夠的空間，避免由于插入報文頭而對報文進行多次拷貝，從而保證數(shù)據(jù)傳輸。
[0009]進一步，服務(wù)器下發(fā)給智能車載終端的報文消息要求在設(shè)備重新注冊成功后發(fā)送到智能車載終端。
[0010]進一步，智能車載終端發(fā)送到服務(wù)器的報文消息要求在智能車載終端重新注冊成功后，發(fā)送到服務(wù)器。
[0011 ]進一步，智能車載終端重啟，沒有發(fā)送到服務(wù)器的的消息，不保存。
[0012]進一步，當(dāng)智能車載終端加電時首先進行按照指定報文格式的注冊報文發(fā)送，所述報文格式包含包頭、包長度、消息編號、命令碼、總包數(shù)、LTE-Fi MAC地址、數(shù)據(jù)內(nèi)容、CRCl 6校驗碼和包尾。
[0013]本發(fā)明具有以下有益效果:
[0014]本發(fā)明的基于UDP協(xié)議實現(xiàn)智能車載終端的接入方法，智能車載終端與服務(wù)器之間采用UDP協(xié)議，基于UDP協(xié)議在智能車載終端與服務(wù)器之間傳輸通道的設(shè)計，在數(shù)據(jù)傳遞時的確認(rèn)機制、重傳機制、擁塞控制機制等都能夠節(jié)省大量的時間，不需要在每臺設(shè)備上維護所有的傳輸連接，當(dāng)智能車載終端數(shù)量居多時，也不會降低網(wǎng)絡(luò)的傳輸效率，避免了丟包、時延等現(xiàn)象的出現(xiàn)，能夠保證智能車載終端的運行。
【附圖說明】
[0015]圖1為基于UDP協(xié)議信息交互的請求應(yīng)答；
[0016]圖2為基于UDP協(xié)議信息交互的請求重發(fā)；
[0017]圖3為基于UDP協(xié)議智能車載終端與服務(wù)器的報文傳輸結(jié)構(gòu)示意圖。
【具體實施方式】
[0018]本發(fā)明基于UDP協(xié)議實現(xiàn)智能車載終端的接入方法如下:
[0019]服務(wù)器接收到智能車載終端請求的報文消息后通過套接字API獲取報文的端口號和IP信息，利用套接字API創(chuàng)建客戶端，每臺智能車載終端對應(yīng)一個套接字客戶端，套接字客戶端用于向智能車載終端回傳響應(yīng)的數(shù)據(jù)報文;采取套接字緩存機制對請求的大容量并發(fā)數(shù)據(jù)包進行處理，待服務(wù)器按照報文格式處理結(jié)束后對智能車載終端進行響應(yīng)。所述套接字緩存機制是指套接字將創(chuàng)建相應(yīng)的套接字緩存，并將智能車載終端的報文消息拷貝到緩存中，當(dāng)報文消息在各協(xié)議層傳輸?shù)倪^程中，將報文頭插入到智能車載終端數(shù)據(jù)之前，套接字緩存為報文頭申請足夠的空間，避免由于插入報文頭而對報文進行多次拷貝，從而保證數(shù)據(jù)傳輸。
[0020]下面結(jié)合附圖對本發(fā)明做進一步詳細描述:
[0021]參見圖1:圖1所示每條報文消息都有一個唯一ID，用于區(qū)分不同的報文消息;設(shè)備注冊成功后會開始一個會話，會話雙方以請求、應(yīng)答模式工作;如果A向B發(fā)出一個請求，B會向A發(fā)出一個應(yīng)答;如果B向A發(fā)出一個請求，A也會向B發(fā)出一個應(yīng)答，請求和應(yīng)答通過報文編號配對；
[0022]圖2是當(dāng)A向B發(fā)出一個請求后，如果A沒有收到響A發(fā)出的應(yīng)答，A會等待一定時間后重新向B發(fā)請求，如果重發(fā)3次后，A仍然沒有收到B向A發(fā)出的應(yīng)答，A結(jié)束會話。當(dāng)B向A發(fā)出一個請求后，如果B在一定時間內(nèi)沒有收到A向B發(fā)出的應(yīng)答，B會向A重發(fā)請求，如果重發(fā)3次后，B仍然沒有收到A向B發(fā)出的應(yīng)答，B結(jié)束會話。
[0023]如上所述的會話在結(jié)束后，以下消息采取如下策略:
[0024]a)服務(wù)器下發(fā)給智能車載終端的報文消息要求在設(shè)備重新注冊成功后發(fā)送到智能車載終端；
[0025]b)智能車載終端發(fā)送到服務(wù)器的報文消息要求在智能車載終端重新注冊成功后，發(fā)送到服務(wù)器；
[0026]c)智能車載終端重啟，沒有發(fā)送到服務(wù)器的的消息，不保存。
[0027]信息交互流程后是智能車載終端與智能車載終端與服務(wù)器之間報文信息的傳輸?shù)陌磮D3所示進行設(shè)計；當(dāng)智能車載終端加電時首先進行按照指定報文格式的注冊報文發(fā)送，所述報文格式包含包頭、包長度、消息編號、命令碼、總包數(shù)、LTE-Fi MAC地址、數(shù)據(jù)內(nèi)容、CRC16校驗碼、包尾;服務(wù)器對智能車載終端請求的報文信息處理包含以下流程:
[0028]1、對CRC16校驗碼進行校驗，如果錯誤，不對智能車載終端進行數(shù)據(jù)包響應(yīng)，如果正確進行下面處理；
[0029]2、對命令碼進行判斷，如果命令碼等于注冊包，然后進行注冊包數(shù)據(jù)內(nèi)容處理，如果服務(wù)器的數(shù)據(jù)庫的庫表中含有該智能車載終端的MAC的地址，則響應(yīng)注冊成功SUCCESS的報文消息，如果服務(wù)器的數(shù)據(jù)庫的庫表中未含有該設(shè)備的信息，則響應(yīng)注冊失敗的FAILD報文消息。
[0030]當(dāng)設(shè)備收到注冊失敗的報文后等待30分鐘重新向服務(wù)器發(fā)送注冊報文請求;智能車載終端對收到注冊成功的報文進行確認(rèn)后進行每隔5分鐘進行一次的心跳報文請求，該心跳報文格式如上文所述，首先還是進行CRC16校驗，校驗通過后對心跳報文的數(shù)據(jù)內(nèi)容進行解析，然后寫入數(shù)據(jù)庫的相應(yīng)庫表中，完成后對智能車載終端進行心跳報文消息的響應(yīng)。
【主權(quán)項】
1.一種基于UDP協(xié)議實現(xiàn)智能車載終端的接入方法，其特征在于，服務(wù)器接收到智能車載終端請求的報文消息后通過套接字API獲取報文的端口號和IP信息，利用套接字API創(chuàng)建客戶端，每臺智能車載終端對應(yīng)一個套接字客戶端，套接字客戶端用于向智能車載終端回傳響應(yīng)的數(shù)據(jù)報文;采取套接字緩存機制對請求的大容量并發(fā)數(shù)據(jù)包進行處理，待服務(wù)器按照報文格式處理結(jié)束后對智能車載終端進行響應(yīng)。2.根據(jù)權(quán)利要求1所述的基于UDP協(xié)議實現(xiàn)智能車載終端的接入方法，其特征在于，所述套接字緩存機制是指套接字將創(chuàng)建相應(yīng)的套接字緩存，并將智能車載終端的報文消息拷貝到緩存中，當(dāng)報文消息在各協(xié)議層傳輸?shù)倪^程中，將報文頭插入到智能車載終端數(shù)據(jù)之前，套接字緩存為報文頭申請足夠的空間，避免由于插入報文頭而對報文進行多次拷貝，從而保證數(shù)據(jù)傳輸。3.根據(jù)權(quán)利要求1所述的基于UDP協(xié)議實現(xiàn)智能車載終端的接入方法，其特征在于，月艮務(wù)器下發(fā)給智能車載終端的報文消息要求在設(shè)備重新注冊成功后發(fā)送到智能車載終端。4.根據(jù)權(quán)利要求1所述的基于UDP協(xié)議實現(xiàn)智能車載終端的接入方法，其特征在于，智能車載終端發(fā)送到服務(wù)器的報文消息要求在智能車載終端重新注冊成功后，發(fā)送到服務(wù)器。5.根據(jù)權(quán)利要求1所述的基于UDP協(xié)議實現(xiàn)智能車載終端的接入方法，其特征在于，智能車載終端重啟，沒有發(fā)送到服務(wù)器的的消息，不保存。6.根據(jù)權(quán)利要求1所述的基于UDP協(xié)議實現(xiàn)智能車載終端的接入方法，其特征在于，當(dāng)智能車載終端加電時首先進行按照指定報文格式的注冊報文發(fā)送，所述報文格式包含包頭、包長度、消息編號、命令碼、總包數(shù)、LTE-Fi MAC地址、數(shù)據(jù)內(nèi)容、CRCl6校驗碼和包尾。
【專利摘要】本發(fā)明公開了一種基于UDP協(xié)議實現(xiàn)智能車載終端的接入方法：服務(wù)器接收到智能車載終端請求的報文消息后通過套接字API獲取報文的端口號和IP信息，利用套接字API創(chuàng)建客戶端，每臺智能車載終端對應(yīng)一個套接字客戶端，套接字客戶端用于向智能車載終端回傳響應(yīng)的數(shù)據(jù)報文；采取套接字緩存機制對請求的大容量并發(fā)數(shù)據(jù)包進行處理，待服務(wù)器按照報文格式處理結(jié)束后對智能車載終端進行響應(yīng)。本發(fā)明基于UDP協(xié)議在智能車載終端與服務(wù)器之間傳輸通道的設(shè)計，在數(shù)據(jù)傳遞時的確認(rèn)機制、重傳機制、擁塞控制機制等都能夠節(jié)省大量時間，當(dāng)智能車載終端數(shù)量居多時，也不會降低網(wǎng)絡(luò)的傳輸效率，避免了丟包、時延等現(xiàn)象的出現(xiàn)，能夠保證智能車載終端的運行。
【IPC分類】H04L29/06, H04W48/16
【公開號】CN105530686
【申請?zhí)枴緾N201510974312
【發(fā)明人】楊杰, 李越
【申請人】西安大唐電信有限公司
【公開日】2016年4月27日
【申請日】2015年12月22日