※ 引述《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有啥应用上以及传输封包上的差异吗？