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