問題一：發不出去
最近做一個小東西改進方案需要用到組播，簡單來說就是我先作為服務器端組播發送設備編號，然后組播成員作為客戶端接收消息后先確認對方是不是在呼叫我。是的話就返回一個消息，這樣我服務器端就可以知道客戶端的IP地址，從而建立TCP連接。
但是在這個過程中一波三折。。。
windows下發送組播消息，樹莓派卻無法接收到這個組播消息，然后使用wireshark抓包看看數據包發出去沒有，結果也沒看見往這個組播地址發送的消息。納尼？我的數據包被誰偷吃了嗎!!!然后上網找解決方案，關閉防火牆，設置端口，設置出入站規則等，然而發現並沒有什么卵用~~~這就很煩躁了，我的數據包呢！
苦尋答案無果，偶然的機會，看到可以查最近加入的組播組（netsh interface ipv4 show joins），然后發現了罪惡之源！
——————華麗的分割線————————
電腦會存在很多虛擬網卡，在發送組播消息的時候通過其他虛擬網卡發送出去了！而這邊樹莓派不在這個網段之類！當然收不到這個組播數據包! 原來是你!偷吃了我的蛋糕！
好吧！關掉關掉關掉!只留下同一子網下的網卡就好了！OK！大功告成！
問題二：無法接收
這邊作為客戶端，收到消息后確認是在叫我當然要禮貌性的回復消息啦！UDP接收消息后會知道發送端的地址，我的做法就按照這個地址返回一個UDP數據包!
那么問題又來了，我接收不到！（因為我兩端都用C語言寫的時候是實現了這個功能的，因為項目原因客戶端代碼是C語言，服務器端是C#，所以這邊改為C#）為什么!這么點東西要這么折磨我！開始以為我的代碼寫錯了（好吧，估計就是我的代碼寫錯了），網上各種找，各種試驗也不行啊！
好像說C#這邊接收不能接收不知道對端IP的數據包（真實性有待考察），C和C#不是親戚嗎？為什么你大哥行你就不行（好像不是親戚）。。。
沒辦法，改變策略。
解決方案：
這邊返回消息也用組播方式，這邊也用組播方式接收消息。好吧，這樣總行了吧！