|
|
昨天搞了一下午的程序，一頭霧水，沒點(diǎn)思路，今天在軟件孫大神的幫助下終于解決這個(gè)問題，
是這樣的嵌入式設(shè)備要和手機(jī)做鏈接，但是為了方便所以把固定IP改成DHCP方式，然后流程是這樣的，第一步嵌入式設(shè)備上點(diǎn)想DHCP服務(wù)器獲取IP地址，然后得到IP地址后啟動(dòng)UDP廣播，向這個(gè)號(hào)段內(nèi)的指定端口廣播一幀數(shù)據(jù)，手機(jī)也在這個(gè)網(wǎng)段內(nèi)，所以收到回復(fù)，我獨(dú)立開辟一個(gè)UDP接受線程接受來自手機(jī)端的數(shù)據(jù)，一旦受到數(shù)據(jù)立馬開始向這個(gè)IP的指定端口做TCP鏈接，完事之后線程掛起開始運(yùn)行TCP客戶端線程，如果在此時(shí)手機(jī)主動(dòng)關(guān)閉TCP鏈接，那么嵌入式設(shè)備要可以重新發(fā)起這個(gè)過程，昨天的現(xiàn)象是，A，第一次可以聯(lián)機(jī)成功，一旦TCP釋放之后無法聯(lián)接，UDP所有的廣播都是正常的，然后用網(wǎng)絡(luò)調(diào)試助手流程都通，沒有一點(diǎn)問題，手機(jī)軟件方面也是所有問題都通，一旦和嵌入式設(shè)備鏈接就不行，原來是這樣的：
只說主要的，其他線程不予考慮。。
系統(tǒng)初始化的時(shí)候創(chuàng)建了2個(gè)主線程，一個(gè)用來初始化網(wǎng)口和上層棧，一個(gè)用來接收UDP數(shù)據(jù)，即A線程B線程，A線程優(yōu)先級(jí)最搞，B線程次之， 然后A線程初始化完畢之后啟動(dòng)DHCP，得到IP地址就開始向此號(hào)段盡享廣播，就是在這個(gè)廣播中出錯(cuò)了，在廣播完畢之后我進(jìn)行了線程睡眠，正事這個(gè)線程睡眠使得系統(tǒng)掛起這個(gè)線程，但是此時(shí)這個(gè)UDP端口沒有注銷，然后轉(zhuǎn)而執(zhí)行B線程，創(chuàng)建好了UDP另一個(gè)端口，就在此時(shí)A線程睡眠完畢，毫不猶豫的搶了B線程的CPU時(shí)間片，導(dǎo)致B線程還沒有完全的執(zhí)行完畢，就被搶走了，如果此時(shí)來一個(gè)UDP包從手機(jī)發(fā)來就會(huì)導(dǎo)致UDP線程收不到，因?yàn)榇藭r(shí)CPU正在A線程處執(zhí)行關(guān)閉端口程序呢，UDP收不到就導(dǎo)致TCP無法啟動(dòng)，那么為什么用網(wǎng)絡(luò)調(diào)試助手可以呢？因?yàn)榫W(wǎng)絡(luò)調(diào)試助手是手動(dòng)的，非常慢，等你發(fā)的時(shí)候A線程早已經(jīng)結(jié)束了關(guān)閉端口命令，而且B線程也得到了足夠的時(shí)間執(zhí)行也堵塞在一個(gè)郵箱上，所以再來UDP數(shù)據(jù)是可以收到的，反之，手機(jī)回復(fù)速度小于線程睡眠時(shí)間，導(dǎo)致A線程搶占B線程，以至于有此事，去掉這個(gè)縣城睡眠，等待A線程老老實(shí)實(shí)執(zhí)行完畢，就好了！哈哈！
sendto(sock, send_data, strlen(send_data), 0,
(struct sockaddr *)&server_addr, sizeof(struct
sockaddr));
thread_delay(50);
close(sock);
此乃罪魁禍?zhǔn)祝?nbsp; 實(shí)在是忽略了呀！實(shí)時(shí)系統(tǒng)！一點(diǎn)想不到就不行啊！坑爹！
|
|
QQ好友和群
QQ空間
騰訊微博
騰訊朋友
收藏
淘帖
頂
踩
