問題是這樣的：UDP協議。
校園網路廣播，服務器軟體向每個教室的終端發送音頻資料，大概每26毫秒發送一次，每次向200個終端發送(每個終端間隔30微妙左右)，每幀的資料長度是512Byte，出現丟包現象，不算太嚴重。
終端那邊的程式應該沒什么問題。因為每26毫秒發送一次，每次向50個終端發送(每個終端間隔30微妙左右)，每幀的資料長度是512Byte，這樣就基本上不出現丟包情況。
想請教一下，怎樣可以太多終端時，盡量避免這種丟包問題呢？
uj5u.com熱心網友回復：
不知道你這所謂不太嚴重是什么概念，你應該以發出多少包，收到多少包，做個壓力測驗，這樣統計出個丟包比例，再來討論。如果只是單純的想解決丟包，可以用udp模擬tcp，這個有現成的庫可以使用。另外如果你發送給所有終端的資料都是相同的話，一個廣播包就可以。uj5u.com熱心網友回復：
要不耍耍流氓 編個號 每個包發兩次
uj5u.com熱心網友回復：
估計超出了你的帶寬。如果20毫秒的間隔，一秒鐘差不多50個包。
每個包512位元組，考慮以太網包頭14位元組，ip包頭20位元組，udp包頭8位元組，總包頭：42位元組
每秒發送：200個終端*50個包*(512+42)位元組＝5,540,000位元組
換算成bit，則相當于50M帶寬。你的校園網有沒有這么大帶寬？
uj5u.com熱心網友回復：
每個包發兩次，我網路就會癱瘓了uj5u.com熱心網友回復：
26毫秒發一次
你得了解熟悉好發送端設備的能力和接收端的接收能力才行吧
而且還512位元組/每幀，這個太大了
我相信如果真能按你的需求做出來的話，設備都是一流的
估計比較可行的是將你需求中的終端都串聯起來或者分版塊串聯區分，或許有可能實作
uj5u.com熱心網友回復：
26毫秒，每秒發40個包左右 ，也沒走校園網，自己組建了一個網，帶寬需求大概35,456,000 BPS 打滿也就36M了
uj5u.com熱心網友回復：
每個包發兩次，我估計網路就癱瘓了，電腦和交換機也不一定能處理得過來uj5u.com熱心網友回復：
doloopcn 方法我也想過，關鍵還需要考慮同步性，如果通過終端轉發，出來的聲音就變得不同步了uj5u.com熱心網友回復：
為什么不壓縮一下呢 ilbchttp://www.cnblogs.com/doorsky/p/3266102.html
uj5u.com熱心網友回復：
壓縮完，終端那邊又需要解壓，終端用的是stm32F107的單片機，而且26毫秒一幀，有點懸啊uj5u.com熱心網友回復：
而且512Byte的音頻資料已經是經過ADPCM壓縮得出來的資料了；uj5u.com熱心網友回復：
發現QQ最小化時會連續丟幾個包，不知QQ最小化觸發了windows的什么事件。uj5u.com熱心網友回復：
有的時候同步只是理想狀態，只要延時在容差允許的范圍內，就行了
就算你現在的方式，也不一定會同步
串聯的方式也許才是真正意義的最接近同步的方式
就像我們搞過的天花音箱工程，喇叭都串聯在一根線上，播放音樂基本沒有異步的感覺
uj5u.com熱心網友回復：
做個流媒體服務端，udp只發送和接收開始和結束的命令uj5u.com熱心網友回復：
如果排除帶寬問題，還有種可能性是發送不及時，可考慮多執行緒或執行緒池方式來處理。uj5u.com熱心網友回復：
既然是廣播又說什么50個終端, 使用UDP不等于使用廣播,廣播是一發多收的.uj5u.com熱心網友回復：
既然是局域網，為什么不直接用UDP廣播，這樣只發送一次就是了另開一個TCP服務，如果終端發現丟包（包序號不連續了），就通過TCP來取，這樣的通訊壓力就小多了
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/63092.html
標籤：網絡通信/分布式開發
上一篇：實作電腦上輸入電話號碼，直接撥號