can匯流排上微控制器與伺服器雙向通訊，伺服器發一次資料等待微控制器響應，響應完成繼續傳送，沒有響應等待1秒再次傳送；微控制器向伺服器傳送資料同理。
can匯流排上共三個節點：stm32+can收發器組成的裝置1與裝置2還有乙太網轉can模組。
問題描述：
裝置1、裝置2、乙太網轉can模組進行頻繁的資料通訊，但測試次數一多容易出現如下問題：裝置1向乙太網轉can模組傳送1幀資料，根據程式顯示明明已經傳送成功了，但是在伺服器端卻沒有收到這幀資料，導致匯流排上產生丟包問題。
思考過程：
在can的通訊過程中有乙個成功接收應答位ack，當stm32通過can傳送1幀資料時，是根據其它節點返回的ack位來判斷是否傳送成功的。以我的理解，原本以為當裝置1傳送1幀資料時，只有可以過濾出裝置1的id號的裝置才會返回這個ack接收應答。所以，這就搞不明白了，如果是這樣那麼接收端明顯已經接受到了這幀資料才會返回的ack位，為什麼在接收端所有的接收資料中卻沒有這幀資料？資料到**去了？
問題答案：
經過領導解答才明白原來並不是只有過濾出裝置1 id號的裝置才會接收並返回ack應答，而是匯流排上的任意乙個裝置都可以接收到這幀資料並返回ack，這是在底層完成的，還沒有到達id號過濾這層操作。當裝置1發出資料檢測到返回的ack應答後這個資料幀就結束了，資訊已經傳送成功。所以當匯流排上的資料交流比較頻繁時，就會出現資料丟包的情況，當裝置1傳送1幀資料到匯流排上，目標是被乙太網轉can模組接收，但是此時乙太網轉can模組正在忙別的事情沒有接收到資料，而這幀資料卻被裝置2接收到了，所以裝置2返回了乙個ack應答，當裝置2進行資料過濾時發現這不是發給自己的資料所以丟棄處理。而此時裝置1因為接收到了ack返回，所以提示資料傳送成功。這就造成資料已經成功傳送到匯流排上，而接收端卻沒有接收到這幀資料的問題。
解決方案：
在can匯流排上的資料交換過程中，不能以can協議中的ack應答位為判斷標準，而是要自己在上層協議中新增判斷，比如裝置1向裝置2傳送一幀資料，裝置2接收到這幀資料後要進行技術應答，當裝置1接收到技術應答後這幀資料才算完成。如果裝置1在規定時間內沒有接收到技術應答應該進行重發處理。就不會因為上述原因造成資料丟失！
Unityclient通訊測試問題處理（二）
unityclient通訊測試問題處理 二 在client的通訊測試過程中。場景載入的問題給自己帶來了不小的麻煩。由於訊息的解析方法在單獨的監聽執行緒中呼叫，這也就意味著無法在訊息的解析方法中呼叫unity自身的api了。本來是打算在接收到場景切換的訊息後，直接在解析方法中呼叫協同程式startco...
壓力測試問題
環境 兩台虛機配置，千m網絡卡 a 8cpu，32g記憶體 應用伺服器 b 2cpu，8g記憶體 資料庫 壓力測試資料 200使用者，每秒響應160 170次左右，cpu占用10 左右，記憶體占用穩定，始終無法提公升，網路使用率4 資料庫伺服器，cpu 2 記憶體占用穩定 資料庫一切正常，伺服器cp...
RabbitMQ 測試問題
使用eventlet併發consumer指令碼 eventlet.monkey patch all true msg per queue 50 queue num 10 rabbit host 10.23.54.150 5672 class consumer def init self,count ...