※ 引述《r596twy (湯姆熊)》之銘言：
: 開發平台(Platform): (Ex: VC++, GCC, Linux, ...)
: Visual studio 2013
: 額外使用到的函數庫(Library Used): (Ex: OpenGL, ...)
: 問題(Question)：
: 寫了Socket的程式，Server端傳檔案，然後Client端接收並寫入檔案
: Multi-thread開N個threads同時去分別接收UDP封包，
: 換句話說，想要將封包拆成N份並同時接收
: 所以預期是希望所需總接收時間會下降
: 但我發現單一thread接收的時間反而比較快...
: 不清楚這可能的問題是甚麼
: 會是因為context switching過多??
: 如果是的話我有辦法從自己的code看出來嗎??
: 補充說明(Supplement)：
: API是使用OpenMP
: 舉個目前測試出的結果，讓大家看看能不能更清楚我可能忽略或做錯的狀況
: thread個數為1時
: 接收10MB的檔案約須時2.5秒
: thread個數為2時
: 若分別接收9MB和1MB，共須時3秒
: 若分別接收5MB和5MB，共須時5秒
透過將多個port打開並同時傳輸後，時間得到預期的結果了
但做一些實驗時，又出現一些怪現象以及一些小疑問：
問題1：
因為測試的Server和Client各是雙核心CPU，所以各開兩個threads去同時傳送和接收
但問題來了，檔案如果傳超過10MB以上，會直接斷線而無法傳完
而且整個網路有一小段時間會呈現網路斷開狀態無法上網...
頻寬沒有被吃光，但網路與socket連線卻斷開了，不清楚是甚麼原因造成這樣
問題2：
我的網路環境是2MB/s，但我用流量觀測軟體去看，發現每秒只用了300KB
我是用Ws2_32.lib和WinSock2.h，是這lib本身有預設傳輸速度嗎？
如果是的話我該如何去調整呢？
問題3：
我是用UDP在傳輸01格式的binary code，目前是用sendto和recvfrom來達成
每次傳輸8個bits，也就是"10010101"諸如此類長度的char出去
而我想問的是，有看到網路上傳輸檔案似乎也有用write/read來達成
這跟sendto/recvfrom有啥應用上以及傳輸封包上的差異嗎？