今天看到seadog007大大發的文章,提到
DNS使用UDP作為底層
想起一個陳年舊案::
我們的IOT硬體/韌體常抱怨Request發了,Server沒回覆,而我們從Server端的Log查不到任何紀錄IOT裝置發送Request的訊息,按照道理說TCP不僅三向交握還會掉包重送,硬體部門也有幾位高手他們說有實現沒收到回覆則反覆發送機制,IOT也校時過的
,所以說原因其實出在DNS/FQDN這裡嗎? 硬體/韌體不肯給我們Log我們也只能用猜的(事實上我的義務已經結束了他們想給我還不想收),各位大大有甚麼看法?
DNS一般是走UDP,所以client端要負責error handle,一般client端的DNS resolver看起來是10秒後retry,retry 3次後回error給上層的AP,IOT因為先天上受比較多限制,DNS resolver/AP是否有作好error handle啊??
那盡量用可被信賴的TCP甚至是HTTP request,取代射後不理的UDP或MAIL或MESSAGE
http甚至還能有LOG存在Server上,我用的IoT(樹莓派)就是走這條路徑在送回傳感器的數據,沒發生有傳沒到或有到沒傳的事
client端如果只知道server的FQDN,就要先透過DNS resolver作FQDN->IP解析才能建connection,再作資料傳輸,如果DNS resolver解不出IP的話,那在server端自然是啥都找不到了,所以說重點在client端的error handle啊....