一種客戶端消息高效的收發(fā)和處理方法及系統(tǒng)的制作方法
【專利摘要】本發(fā)明公開了一種客戶端消息高效的收發(fā)和處理方法及系統(tǒng)。方法包括處理步驟：利用發(fā)送隊(duì)列和單個(gè)處理線程實(shí)現(xiàn)客戶端的收發(fā)和處理邏輯，所述發(fā)送隊(duì)列用于存儲(chǔ)發(fā)送請求消息，所述處理線程用于發(fā)送請求消息、接收并處理服務(wù)器發(fā)過來的消息。系統(tǒng)包括：發(fā)送隊(duì)列模塊，用于存儲(chǔ)客戶端的請求信息；處理模塊，用于發(fā)送請求消息、接收并處理服務(wù)器發(fā)過來的消息。本發(fā)明一種客戶端消息高效的收發(fā)和處理方法利用發(fā)送隊(duì)列和單個(gè)處理線程實(shí)現(xiàn)客戶端的收發(fā)和處理邏輯，即是使用較少的資源實(shí)現(xiàn)了較高的收發(fā)成功率和較好的交互實(shí)時(shí)性。本發(fā)明可以廣泛應(yīng)用于各種客戶端和服務(wù)器的消息交互系統(tǒng)。
【專利說明】一種客戶端消息高效的收發(fā)和處理方法及系統(tǒng)

【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及網(wǎng)絡(luò)數(shù)據(jù)通信領(lǐng)域，尤其涉及一種客戶端消息的收發(fā)和處理方法，本發(fā)明還涉及一種客戶端消息的收發(fā)和處理系統(tǒng)。

【背景技術(shù)】
[0002]服務(wù)器和客戶端又叫主從式架構(gòu)，簡稱C/S結(jié)構(gòu)，是一種網(wǎng)絡(luò)架構(gòu)，每一個(gè)客戶端軟件的實(shí)例都可以向服務(wù)器發(fā)出請求。在實(shí)現(xiàn)服務(wù)器和客戶端的交互中，常見的收發(fā)方式有兩種:一收一發(fā)方式和常規(guī)隊(duì)列方式。
[0003]如圖1所示，一收一發(fā)方式:即客戶端發(fā)出一個(gè)請求后(M11)，會(huì)設(shè)置一個(gè)接收超時(shí)時(shí)間(Ml2 )。如果在這個(gè)時(shí)間內(nèi)收到了對方的響應(yīng)(Ml3 )，則認(rèn)為發(fā)送成功(Ml5 )，從而可以繼續(xù)處理其他的業(yè)務(wù)，否則會(huì)認(rèn)為發(fā)送失敗(M16)，進(jìn)而考慮是否進(jìn)行重發(fā)處理或者是其他處理機(jī)制。由于網(wǎng)絡(luò)環(huán)境好壞往往是不可知的，所以通常會(huì)選擇一個(gè)比較長的超時(shí)時(shí)間來等待服務(wù)器的響應(yīng)。這樣可以在一定程度上提高收發(fā)的成功率。但是如果服務(wù)器發(fā)送響應(yīng)由于網(wǎng)絡(luò)的原因而無法正常到達(dá)客戶端，這將會(huì)導(dǎo)致主進(jìn)程在超時(shí)時(shí)間內(nèi)空等，而無法再做其他的工作。如果在超時(shí)時(shí)間內(nèi)收到的不是當(dāng)前期望的響應(yīng)(M14)，這個(gè)模式也無法處理，通常的做法是直接丟掉，從而造成丟包的現(xiàn)象。
[0004]如圖2所示，常規(guī)隊(duì)列模式:這種模式不直接操作收發(fā)接口?？蛻舳酥髁鞒讨袑⒄埱筇砑拥桨l(fā)送隊(duì)列(M21、M22)后，然后設(shè)置一個(gè)超時(shí)時(shí)間，然后在這段時(shí)間內(nèi)不斷查詢服務(wù)器是否做出了正確的響應(yīng)(M23)。由于客戶端主線程不需要直接處理收發(fā)邏輯，而只是通過將請求添加到隊(duì)列和查詢狀態(tài)標(biāo)志的形式來間接實(shí)現(xiàn)與服務(wù)器的交互(M24)，所以客戶端的主流程不會(huì)造成較長時(shí)間的阻塞，從而使主流程變得高效，直接提高了客戶端和服務(wù)器的交互能力。當(dāng)然這種方式之所以能解決一發(fā)一收方式中的難于解決的一些問題，完全要?dú)w功于常規(guī)隊(duì)列模式中必須要額外的創(chuàng)建出兩個(gè)線程和至少一個(gè)發(fā)送隊(duì)列來支持。發(fā)送線程用于不斷輪詢發(fā)送隊(duì)列中是否有請求需要發(fā)送(BS1)，如果有則發(fā)送(BS2)，沒有則繼續(xù)查詢。接收線程用于處理來自服務(wù)器的響應(yīng)(BRl)并設(shè)置響應(yīng)的標(biāo)志位(BR2)，用于客戶端主流程查詢。而且這種模式將每個(gè)線程賦予不同的單一的功能，從而使這個(gè)代碼框架變得簡潔，可以很好的減少代碼的冗余，使代碼更加健壯。但這種方式的缺點(diǎn)也是顯而易見的。首先它的開銷比較大，其次需要額外增加代碼來實(shí)現(xiàn)發(fā)送隊(duì)列，最大的不足是它依然無法解決在客戶端等待響應(yīng)時(shí)但收到的卻是服務(wù)器請求的情況。


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

[0005]為了解決上述技術(shù)問題，本發(fā)明的目的是提供一種高效、節(jié)省系統(tǒng)開銷的消息收發(fā)和處理方法。
[0006]為了解決上述技術(shù)問題，本發(fā)明的另一個(gè)目的是提供一種高效、節(jié)省系統(tǒng)開銷的消息收發(fā)和處理系統(tǒng)。
[0007]本發(fā)明所采用的技術(shù)方案是: 一種客戶端消息高效的收發(fā)和處理方法，其包括處理步驟:利用發(fā)送隊(duì)列和單個(gè)處理線程實(shí)現(xiàn)客戶端的收發(fā)和處理邏輯，所述發(fā)送隊(duì)列用于存儲(chǔ)發(fā)送請求消息，所述處理線程用于發(fā)送請求消息、接收并處理服務(wù)器發(fā)過來的消息。
[0008]優(yōu)選的，所述處理步驟具體為:S1，檢查發(fā)送隊(duì)列是否為空，如果為空則跳到步驟S3，否則進(jìn)入步驟S2 ;S2，從發(fā)送隊(duì)列中取出發(fā)送請求并發(fā)送；S3，等待服務(wù)器回復(fù)，并檢查是否超時(shí)，如果超時(shí)，則跳到步驟SI，否則進(jìn)入步驟S4 ;S4，檢查是否收到服務(wù)器發(fā)過來的消息，如果收到，則進(jìn)入步驟S5，否則跳回步驟S3 ;S5，檢查收到的消息是否是發(fā)送請求的響應(yīng)，如果是，則進(jìn)入步驟S6 ;S6，處理服務(wù)器響應(yīng)并將成功標(biāo)志位置位，再返回步驟SI。
[0009]優(yōu)選的，其還包括步驟:S7，檢查收到的消息是否是服務(wù)器的請求消息，如果是，則進(jìn)入步驟S8，否則跳到步驟S3 ;S8，處理服務(wù)器的請求消息，再跳到步驟S3。
[0010]優(yōu)選的，所述步驟S5具體包括子步驟:S51，檢查收到的消息是否是發(fā)送請求的響應(yīng)；S52，如果S51的檢查結(jié)果為是，則進(jìn)入步驟S6，否則進(jìn)入步驟S7。
[0011]優(yōu)選的，其還包括客戶端主線程步驟，所述主線程步驟具體為:M1，將請求消息添加到發(fā)送隊(duì)列；M2，檢查是否超時(shí)，如果超時(shí)則跳到步驟M5，否則進(jìn)入步驟M3 ;M3，檢查成功標(biāo)志是否被置，如被置則進(jìn)入步驟M4，否則跳到步驟M2 ;M4，請求成功；M5，請求失敗。
[0012]一種客戶端消息高效的收發(fā)和處理系統(tǒng)，其用于實(shí)施一種客戶端消息高效的收發(fā)和處理方法，其包括:發(fā)送隊(duì)列模塊，用于存儲(chǔ)客戶端的請求信息；處理模塊，用于發(fā)送請求消息、接收并處理服務(wù)器發(fā)過來的消息。
[0013]優(yōu)選的，所述處理模塊包括:發(fā)送單元，用于從發(fā)送隊(duì)列中取出發(fā)送請求并發(fā)送；接收單元，用于接收服務(wù)器發(fā)過來的消息；判斷單元，用于判斷收到的消息是否是發(fā)送請求的響應(yīng)；處理單元，用于處理服務(wù)器的響應(yīng)，并將成功標(biāo)志置位。
[0014]優(yōu)選的，所述判斷單元還用于判斷收到的消息是否是服務(wù)器的請求消息；所述處理單元還用于處理服務(wù)器的請求消息。
[0015]優(yōu)選的，其還包括客戶端主線程，所述客戶端主線程包括:請求消息接收單元，用于將請求消息添加到發(fā)送隊(duì)列；計(jì)時(shí)單元，用于檢查等待時(shí)間是否超時(shí)；檢查單元，用于檢查檢查成功標(biāo)志是否被置。
[0016]本發(fā)明的有益效果是:
本發(fā)明一種客戶端消息高效的收發(fā)和處理方法利用發(fā)送隊(duì)列和單個(gè)處理線程實(shí)現(xiàn)客戶端的收發(fā)和處理邏輯，使得客戶端主流程不會(huì)造成較長時(shí)間的阻塞，從而使主流程變得高效，直接提高了客戶端和服務(wù)器的交互能力，與此同時(shí)，系統(tǒng)的開銷小，而且可以有效處理在客戶端等待響應(yīng)時(shí)收到的服務(wù)器的請求消息，即是使用較少的資源實(shí)現(xiàn)了較高的收發(fā)成功率和較好的交互實(shí)時(shí)性。
[0017]本發(fā)明可以廣泛應(yīng)用于各種客戶端和服務(wù)器的消息交互系統(tǒng)。
[0018]本發(fā)明的另一個(gè)有益效果是:
本發(fā)明一種客戶端消息高效的收發(fā)和處理系統(tǒng)利用發(fā)送隊(duì)列和單個(gè)處理線程實(shí)現(xiàn)客戶端的收發(fā)和處理邏輯，使得客戶端主流程不會(huì)造成較長時(shí)間的阻塞，從而使主流程變得高效，直接提高了客戶端和服務(wù)器的交互能力，與此同時(shí)，系統(tǒng)的開銷小，而且可以有效處理在客戶端等待響應(yīng)時(shí)收到的服務(wù)器的請求消息，即是使用較少的資源實(shí)現(xiàn)了較高的收發(fā)成功率和較好的交互實(shí)時(shí)性。
[0019]本發(fā)明可以廣泛應(yīng)用于各種客戶端和服務(wù)器的消息交互系統(tǒng)。

【專利附圖】

【附圖說明】
[0020]下面結(jié)合附圖對本發(fā)明的【具體實(shí)施方式】作進(jìn)一步說明:
圖1是現(xiàn)有技術(shù)一收一發(fā)方式的方法流程示意圖；
圖2是現(xiàn)有技術(shù)常規(guī)隊(duì)列模式的方法流程示意圖；
圖3是本發(fā)明客戶端消息高效的收發(fā)和處理方法處理線程一種實(shí)施例的流程示意圖； 圖4是本發(fā)明客戶端消息高效的收發(fā)和處理方法客戶端主流程一種實(shí)施例的流程示意圖。

【具體實(shí)施方式】
[0021]需要說明的是，在不沖突的情況下，本申請中的實(shí)施例及實(shí)施例中的特征可以相互組合。
[0022]如圖4所示，一種客戶端消息高效的收發(fā)和處理方法，其包括處理步驟:利用發(fā)送隊(duì)列和單個(gè)處理線程實(shí)現(xiàn)客戶端的收發(fā)和處理邏輯，所述發(fā)送隊(duì)列用于存儲(chǔ)發(fā)送請求消息，所述處理線程用于發(fā)送請求消息、接收并處理服務(wù)器發(fā)過來的消息。
[0023]優(yōu)選的，所述處理步驟具體為:S1，檢查發(fā)送隊(duì)列是否為空，如果為空則跳到步驟S3，否則進(jìn)入步驟S2 ;S2，從發(fā)送隊(duì)列中取出發(fā)送請求并發(fā)送；S3，等待服務(wù)器回復(fù)，并檢查是否超時(shí)，如果超時(shí)，則跳到步驟SI，否則進(jìn)入步驟S4 ;S4，檢查是否收到服務(wù)器發(fā)過來的消息，如果收到，則進(jìn)入步驟S5，否則跳回步驟S3 ;S5，檢查收到的消息是否是發(fā)送請求的響應(yīng)，如果是，則進(jìn)入步驟S6 ;S6，處理服務(wù)器響應(yīng)并將成功標(biāo)志位置位，再返回步驟SI。該實(shí)施例中，客戶端消息高效的收發(fā)和處理方法只需要一個(gè)發(fā)送隊(duì)列和單個(gè)處理線程就可以實(shí)現(xiàn)，這點(diǎn)上看它比常規(guī)隊(duì)列模式需要較少的資源。高效模式將常規(guī)模式中發(fā)送線程和接收線程的功能整合在一起。用一個(gè)收發(fā)線程來實(shí)現(xiàn)收發(fā)和處理邏輯。
[0024]該實(shí)施例中，所述步驟S5具體包括子步驟:S51，檢查收到的消息是否是發(fā)送請求的響應(yīng)；S52，如果S51的檢查結(jié)果為是，則進(jìn)入步驟S6，否則進(jìn)入步驟S7。處理線程還包括步驟:S7，檢查收到的消息是否是服務(wù)器的請求消息，如果是，則進(jìn)入步驟S8,否則跳到步驟S3 ;S8，處理服務(wù)器的請求消息，再跳到步驟S3 ;所述步驟S5還包括子步驟:S54，如果S51檢查結(jié)果為否，則進(jìn)入步驟S7。
[0025]客戶端消息高效的收發(fā)和處理方法在收到服務(wù)器的響應(yīng)之后，實(shí)現(xiàn)如果該響應(yīng)不是主流程所期待的響應(yīng)能夠正確處理。解決了常規(guī)隊(duì)列模式不能解決的問題。如果在等待服務(wù)器響應(yīng)期間收到的是服務(wù)器的請求也會(huì)有相應(yīng)的流程來處理，而且會(huì)將處理后產(chǎn)生的客戶端響應(yīng)直接通過發(fā)送接口發(fā)送出去，而不是將客戶端響應(yīng)又再次添加到發(fā)送隊(duì)列，這有助于提尚對服務(wù)器請求響應(yīng)的實(shí)時(shí)性。能有效的提尚收發(fā)的成功率和交互的實(shí)時(shí)性。簡單地講就是服務(wù)器的請求會(huì)比客戶端的請求優(yōu)先級較高，將客戶端的請求添加到發(fā)送隊(duì)列可以減少客戶端主流程的等待時(shí)間，使客戶端主線程能盡快空閑下來處理其他業(yè)務(wù)。而在收發(fā)線程中，由于服務(wù)器請求比客戶端的請求的優(yōu)先級高，所以如果在等待服務(wù)器響應(yīng)的過程中收到了服務(wù)器的請求，就會(huì)立刻處理這個(gè)請求，這個(gè)請求處理完成后再接著等待服務(wù)器的響應(yīng)，直至收到這個(gè)請求對應(yīng)的響應(yīng)或者超時(shí)。將優(yōu)先級機(jī)制引入客戶端業(yè)務(wù)處理流程中，使得客戶端在處理本地請求的同時(shí)能夠優(yōu)先處理服務(wù)器的請求，能有效的提高收發(fā)的成功率和交互的實(shí)時(shí)性。
[0026]如圖3所示，其還包括客戶端主線程步驟，所述主線程步驟具體為:M1，將請求消息添加到發(fā)送隊(duì)列；M2，檢查是否超時(shí)，如果超時(shí)則跳到步驟M5，否則進(jìn)入步驟M3 ;M3，檢查成功標(biāo)志是否被置，如被置則進(jìn)入步驟M4，否則跳到步驟M2 ;M4，請求成功；M5，請求失敗?？蛻舳讼⒏咝У氖瞻l(fā)和處理方法是對常規(guī)隊(duì)列處理模式的優(yōu)化。比較圖2和圖4可以看到，它們的客戶端主流程都是一樣的。所以客戶端消息高效的收發(fā)和處理方法具備了常規(guī)隊(duì)列模式的所有優(yōu)點(diǎn)。
[0027]本發(fā)明一種客戶端消息高效的收發(fā)和處理方法利用發(fā)送隊(duì)列和單個(gè)處理線程實(shí)現(xiàn)客戶端的收發(fā)和處理邏輯，使得客戶端主流程不會(huì)造成較長時(shí)間的阻塞，從而使主流程變得高效，直接提高了客戶端和服務(wù)器的交互能力，與此同時(shí)，系統(tǒng)的開銷小，而且可以有效處理在客戶端等待響應(yīng)時(shí)收到的服務(wù)器的請求消息，即是使用較少的資源實(shí)現(xiàn)了較高的收發(fā)成功率和較好的交互實(shí)時(shí)性。本發(fā)明可以廣泛應(yīng)用于各種客戶端和服務(wù)器的消息交互系統(tǒng)。
[0028]一種客戶端消息高效的收發(fā)和處理系統(tǒng)，其用于實(shí)施一種客戶端消息高效的收發(fā)和處理方法，其包括:發(fā)送隊(duì)列模塊，用于存儲(chǔ)客戶端的請求信息；處理模塊，用于發(fā)送請求消息、接收并處理服務(wù)器發(fā)過來的消息。
[0029]優(yōu)選的，所述處理模塊包括:發(fā)送單元，用于從發(fā)送隊(duì)列中取出發(fā)送請求并發(fā)送；接收單元，用于接收服務(wù)器發(fā)過來的消息；判斷單元，用于判斷收到的消息是否是發(fā)送請求的響應(yīng)；處理單元，用于處理服務(wù)器的響應(yīng)，并將成功標(biāo)志置位。
[0030]優(yōu)選的，所述判斷單元還用于判斷收到的消息是否是服務(wù)器的請求消息；所述處理單元還用于處理服務(wù)器的請求消息。
[0031]優(yōu)選的，其還包括客戶端主線程，所述客戶端主線程包括:請求消息接收單元，用于將請求消息添加到發(fā)送隊(duì)列；計(jì)時(shí)單元，用于檢查等待時(shí)間是否超時(shí)；檢查單元，用于檢查成功標(biāo)志是否被置。
[0032]一種客戶端消息高效的收發(fā)和處理系統(tǒng)的實(shí)現(xiàn)原理對應(yīng)于一種客戶端消息高效的收發(fā)和處理方法，在此不做贅述。
[0033]本發(fā)明一種客戶端消息高效的收發(fā)和處理系統(tǒng)利用發(fā)送隊(duì)列和單個(gè)處理線程實(shí)現(xiàn)客戶端的收發(fā)和處理邏輯，使得客戶端主流程不會(huì)造成較長時(shí)間的阻塞，從而使主流程變得高效，直接提高了客戶端和服務(wù)器的交互能力，與此同時(shí)，系統(tǒng)的開銷小，而且可以有效處理在客戶端等待響應(yīng)時(shí)收到的服務(wù)器的請求消息，即是使用較少的資源實(shí)現(xiàn)了較高的收發(fā)成功率和較好的交互實(shí)時(shí)性。本發(fā)明可以廣泛應(yīng)用于各種客戶端和服務(wù)器的消息交互系統(tǒng)。
[0034]以上是對本發(fā)明的較佳實(shí)施進(jìn)行了具體說明，但本發(fā)明創(chuàng)造并不限于所述實(shí)施例，熟悉本領(lǐng)域的技術(shù)人員在不違背本發(fā)明精神的前提下還可做作出種種的等同變形或替換，這些等同的變形或替換均包含在本申請權(quán)利要求所限定的范圍內(nèi)。
【權(quán)利要求】
1.一種客戶端消息高效的收發(fā)和處理方法，其特征在于，其包括步驟:利用發(fā)送隊(duì)列和單個(gè)處理線程實(shí)現(xiàn)客戶端的收發(fā)和處理邏輯，所述發(fā)送隊(duì)列用于存儲(chǔ)發(fā)送請求消息，所述處理線程用于發(fā)送請求消息、接收并處理服務(wù)器發(fā)過來的消息。
2.根據(jù)權(quán)利要求1所述的客戶端消息高效的收發(fā)和處理方法，其特征在于，所述步驟具體為: S1,檢查所述發(fā)送隊(duì)列是否為空，如果為空則跳到步驟S3，否則進(jìn)入步驟S2 ; S2，從所述發(fā)送隊(duì)列中取出發(fā)送請求并發(fā)送； S3，等待服務(wù)器回復(fù)，并檢查是否超時(shí)，如果超時(shí)，則跳到步驟S1，否則進(jìn)入步驟S4 ; S4，檢查是否收到服務(wù)器發(fā)過來的消息，如果收到，則進(jìn)入步驟S5，否則跳回步驟S3 ; S5，檢查收到的消息是否是發(fā)送請求的響應(yīng)，如果是，則進(jìn)入步驟S6 ; S6，處理服務(wù)器響應(yīng)并將成功標(biāo)志位置位，再返回步驟S1。
3.根據(jù)權(quán)利要求2所述的客戶端消息高效的收發(fā)和處理方法，其特征在于，其還包括步驟: S7,檢查收到的消息是否是服務(wù)器的請求消息，如果是，則進(jìn)入步驟S8,否則跳到步驟S3 ； S8，處理服務(wù)器的請求消息，再跳到步驟S3。
4.根據(jù)權(quán)利要求3所述的客戶端消息高效的收發(fā)和處理方法，其特征在于:所述步驟S5具體包括子步驟: S51，檢查收到的消息是否是發(fā)送請求的響應(yīng)； S52，如果S51的檢查結(jié)果為是，則進(jìn)入步驟S6，否則進(jìn)入步驟S7。
5.根據(jù)權(quán)利要求1至4任一項(xiàng)所述的客戶端消息高效的收發(fā)和處理方法，其特征在于，其還包括客戶端主線程步驟，所述主線程步驟具體為: M1，將請求消息添加到發(fā)送隊(duì)列； M2，檢查是否超時(shí)，如果超時(shí)則跳到步驟M5，否則進(jìn)入步驟M3 ; M3，檢查成功標(biāo)志是否被置，如被置則進(jìn)入步驟M4，否則跳到步驟M2 ; M4，請求成功； M5，請求失敗。
6.一種客戶端消息高效的收發(fā)和處理系統(tǒng)，其特征在于，其用于實(shí)施如權(quán)利要求1至5任意一項(xiàng)所述的客戶端消息高效的收發(fā)和處理方法，其包括: 發(fā)送隊(duì)列模塊，用于存儲(chǔ)客戶端的請求信息； 處理模塊，用于發(fā)送請求消息、接收并處理服務(wù)器發(fā)過來的消息。
7.根據(jù)權(quán)利要求6所述的客戶端消息高效的收發(fā)和處理系統(tǒng)，其特征在于，所述處理模塊包括: 發(fā)送單元，用于從發(fā)送隊(duì)列中取出發(fā)送請求并發(fā)送； 接收單元，用于接收服務(wù)器發(fā)過來的消息； 判斷單元，用于判斷收到的消息是否是發(fā)送請求的響應(yīng)； 處理單元，用于處理服務(wù)器的響應(yīng)，并將成功標(biāo)志置位。
8.根據(jù)權(quán)利要求7所述的客戶端消息高效的收發(fā)和處理系統(tǒng)，其特征在于:所述判斷單元還用于判斷收到的消息是否是服務(wù)器的請求消息；所述處理單元還用于處理服務(wù)器的請求消息。
9.根據(jù)權(quán)利要求6至8任一項(xiàng)所述的客戶端消息高效的收發(fā)和處理系統(tǒng)，其特征在于，其還包括客戶端主線程，所述客戶端主線程包括: 請求消息接收單元，用于將請求消息添加到發(fā)送隊(duì)列； 計(jì)時(shí)單元，用于檢查等待時(shí)間是否超時(shí)； 檢查單元，用于檢查檢查成功標(biāo)志是否被置。
【文檔編號】H04L29/08GK104506642SQ201410842195
【公開日】2015年4月8日 申請日期:2014年12月30日 優(yōu)先權(quán)日:2014年12月30日
【發(fā)明者】廖子強(qiáng), 陳勇全, 符鎮(zhèn)一, 唐澤鵬, 鄭宏連, 趙兵 申請人:深圳市蘭丁科技有限公司