最近處理乙個關於簡訊的問題，debug過程中有遇到一些障礙和彎路。問題是手機應該收到一條語音信箱的簡訊，但是一直沒有收到。modem已經上報了簡訊的pdu，但是framework解析之後進行dispatch失敗了。對pdu的decode和dispatch都是google aosp的，第一感覺應該是framework應該沒有問題，應該是pdu的格式不符合spec造成的，使用工具解析pdu後並沒有發現什麼問題，又回到error的地方，發現是乙個service處理的pdu，這個service可以客戶override，所以就馬上懷疑應該是客戶override的這個service出現的問題，service處理的pdu已經是framework decode後的user data了，但是service依然用這個資料create pdu，導致判讀長度失敗了。發現問題的根本原因後，當時就準備給客戶乙個temp patch，解決掉這個問題。在準備給客戶詳細的問題原因和temp patch的時候發現，對於正常的wap pdu簡訊應該走不到出現error的地方，就又重新回到解析pdu的地方，發信原來這個pdu的teleservice id是wap push的，但是dest port不是，導致不能正常dispatch，而進入了正常簡訊的處理流程，而wap pdu的處理和普通簡訊是不一樣的。問題發信後，只能請底層的owner來檢視問題了，是pdu的teleservice id不對還是dest port不對。
如果對簡訊模組不熟悉，沒有關係，問題其實就是如何確定問題發生的點，以及如何寫code，是讓問題盡快的暴露出來，還是做一些error handling讓問題不發生在自己負責的模組裡面呢？這個簡訊的問題，其實底層就可以check出當前的pdu是否符合spec，如果不符合spec就不要上報，打出為什麼沒有上報的原因，這樣問題就會很容易查詢。但是底層是直接把pdu傳送給framework進行處理，而framework是處理不下去了，才出現的error，而從error出現的地方就很難知道為什麼會出現error，為什麼會走到這裡。如果對code不熟悉，可能會新增一些error handling，讓**正常運轉，但是真實的問題點可能就會掩蓋掉，甚至問題只是不發生在自己的模組，而發生在別的模組了。
現在的軟體都是分層的，資料在不同層進行傳輸，運算元據，這樣每層可能都會帶來問題，當自己身處於某個層的時候，對於接收到的資料，應該和自己的底層做好明確的定義，資料格式應該是什麼，什麼樣的資料是正確的，什麼樣式錯誤，這樣就能把責任劃清。資料格式正確，問題發生在自己的層，那應該就是自己的**邏輯的問題，如果資料格式錯誤，就應該傳輸資料層處理，為什麼出入錯誤的資料。最討厭的是，責任不明確，問題誰處理都可以，這樣會造成討論時間的浪費和相互扯皮，只是浪費時間和浪費情感。
從軟體各種書籍看，問題越提早發現越好，越容易處理，但是有時候我們不能要求別人，只能自己管好自己，對傳入的資料進行校驗，保證自己的**邏輯處理的是正確資料，如果是錯誤資料就馬上停止執行，輸出錯誤資訊，可能需要自己新增乙個資料校驗層。
總結起來就是，層與層之間一定要做好定義，按照大家討論好的標準來做，做好責任劃分。如果責任一直沒有劃分好，我們盡可能地推動這件事件，如果推動不了，那就盡可能的讓自己的**邏輯足夠的健壯和容易debug。另外如果有時間，可以適當了解上下層的處理邏輯，這樣溝通起來更方便，更順暢。
如何更高效的在層與層之間呼叫
遇到乙個新的框架，分為action，ao，bo，dao，service這幾層。action層基於coc。ao，bo，dao又使用的是spring管理的。action與ao間使用的名稱呼叫，如 private string aoname cpsmyauctionao result result exe...
2層交換機與3層交換機之間到底有什麼差別！
網路技術發展迅猛，乙太網佔據了統治地位。為了適應網路應用深化帶來的挑戰，網路的規模和速度都在急劇發展，區域網的速度已從最初的10mbit s提高到100mbit s，千兆乙太網技術也已得到了普遍應用。對於使用者來說，在減低成本的前提下，保證網路的高可靠性 高效能 易維護 易擴充套件，與採用何種組網技...
二層攻擊與安全問題
vlan攻擊 1 vlan跳轉 攻擊原理 通過改變trunk鏈路中封裝的資料報的vlan id,攻擊裝置可以傳送或者接收不同vlan中的資料報，而繞過三層安全性機制 解決方法 加強trunk配置和未使用埠的協商狀態 把未使用的埠放入公共vlan 2 公共裝置vlan之間的攻擊 攻擊原理 即使是公共v...