[問題] 請問UDP socket的SO_RCVBUF問題

看板C_and_CPP (C/C++)作者 (2orx)時間14年前 (2011/10/08 12:54), 編輯推噓5(5018)
留言23則, 5人參與, 最新討論串1/1
請問各位高手 小弟最近在作一個UDP echo server的實驗 client端會在區網送大量的封包, 導致socket buffer被塞爆而掉包 我利用setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int)) 的方式加大buffer就可有效解決掉包問題 我的問題是, 如果我不管傳輸環境的traffic有多大, 一律把buffer調到最大 他會對效能有什麼不好的影響嗎?(比如說在traffic沒這麼大的環境裡) 如果不會有壞影響, 何不所有socket server程式都調大buffer, 這樣不是可以 順應各種traffic的loading嗎? (P.S. 我知道connection oriented的protocol不需要, 如TCP, SCTP等) 請各位解惑了謝謝~ 我的環境是CentOS 5.5 kernel為linux 2.6.18 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.135.253.175 ※ 編輯: hn12303158 來自: 220.135.253.175 (10/08 12:54)

10/08 13:01, , 1F
用UDP又不想掉包的理由?
10/08 13:01, 1F

10/08 13:04, , 2F
不是不想掉包, 是掉包情況太嚴重
10/08 13:04, 2F

10/08 13:06, , 3F
我的client端在10秒內發送1102Byte的大封包50000次
10/08 13:06, 3F

10/08 13:06, , 4F
那麼改成問"用UDP的理由?"
10/08 13:06, 4F

10/08 13:08, , 5F
平均流量有1102*8*50000/10 大約有44.1 mbps
10/08 13:08, 5F

10/08 13:09, , 6F
而我的server端大概只能fetch到40%以下的UDP封包
10/08 13:09, 6F

10/08 13:10, , 7F
結果慘不忍睹, 但調大buffer後情況改善很多
10/08 13:10, 7F

10/08 13:11, , 8F
哈哈...這說來話長^^" 我說"UDP echo server"其實只是
10/08 13:11, 8F

10/08 13:11, , 9F
簡化問題, 真正在作的東西是一個protocol transform的
10/08 13:11, 9F

10/08 13:12, , 10F
Gateway, 不能(也不需要)TCP或SCTP提供的flow control
10/08 13:12, 10F

10/08 18:52, , 11F
你所謂加大是加到多大?
10/08 18:52, 11F

10/08 20:24, , 12F
改用 udt 如何?
10/08 20:24, 12F

10/09 15:51, , 13F
我把rev和send buffer都修改到2MB, 另外, 我實作的東西
10/09 15:51, 13F

10/09 15:52, , 14F
其實是一個標準, 所以不能更改UDP為UDT
10/09 15:52, 14F

10/09 16:58, , 15F
你如何證明2MB足以應付各種場合?
10/09 16:58, 15F

10/09 20:21, , 16F
littleshan你誤會我的意思了, 我是問說如果我加大buff
10/09 20:21, 16F

10/09 20:22, , 17F
沒有負作用的話, 那何不以後實作server程式都將其加大
10/09 20:22, 17F

10/09 20:23, , 18F
到MAX值; 並非我加大到2M就足以應付各種場合
10/09 20:23, 18F

10/09 20:24, , 19F
加大buff 比較有效的應該是對付暴衝的流量, 長時間大流
10/09 20:24, 19F

10/09 20:25, , 20F
量下來, buff怎麼大都不夠用 (吧)
10/09 20:25, 20F

10/09 20:26, , 21F
eric大說的有理, 但是這樣作也沒有缺點事嗎? 我想確認
10/09 20:26, 21F

10/09 20:26, , 22F
的是這件事
10/09 20:26, 22F

10/10 09:55, , 23F
一是memory不一定夠用,二是加大了也不見得能解決問題
10/10 09:55, 23F
文章代碼(AID): #1EZzTf2i (C_and_CPP)
文章代碼(AID): #1EZzTf2i (C_and_CPP)