winsock接收高速数据的问题

Question

不管是微软的winsock还是论坛上流行的SocketMaster，都有这个大问题，就是在接收低速数据时还正常（例如在1个/秒以上），而在数据包速率较高时（例如1个/秒以下），就开始分不清数据包。例如我的数据包在正常接收时bytesTotal为2000，而速度一快就可能2个合并到一起为4000，再快就是8000了（winsock的缓存最大为8192）。
不知这个问题该怎么解决？只能靠自定义的长度指示？

Answer 1

通信的协议当然一般都是如此。例如7号信令、LAPD信令等都是如此。不过还真是第一次亲眼看到密集数据包轰击接收程序的情景。
我现在担心的是winsock缓存只有8192B，密集数据包传来后会不会丢包。例如假设一个原始数据包是2000B，4个原始包8000B，第5个包会有192B在这一个DataArrival里，剩下的1808B会怎么样呢？在下一个DataArrival里？打乱头尾？还是第5个就丢了？如果来不及处理，后面的包会丢吗？
我想用程序验证一下，有结果发在楼下。

Answer 2

多个数据包首尾相接粘在一起的问题是在发送端造成的。如果不想自定义包的结构，就在发送端每次senddata后面加一个doevents，这样不管这次senddata的数据有多少，都会立即发送出去，而不是先放入缓冲区，造成多次数据粘在一起。
另外，如果你使用tcp/ip协议，那么不必担心会丢包。

Answer 3

目前我的系统与信息亭的winsock+tcp/ip通讯还没遇到这个问题。关注中......

Answer 4

我用的是tcp而不是udp，我也知道tcp是需要确认的，理论上我知道不会丢包，但是会不会接收端处理过慢导致发送端拥塞呢？

Answer 5

新手的發言....如有誤請指正
一般來說 tcp 都不太會出錯 .記的剛學vb 時 我是由通訊學起..
遇到的問題如下:
1.DOEVENTS ...3樓大大的話我同感  ..雖然TCP 但我還是會在 senddata 後加個 doevents
2.網路是不是阻塞(沒開迅雷或bt 下載1xxx多筆客戶資料 下載完  比對均無誤  但一開迅雷或bt 居然資料會有錯誤)
3.視訊用tcp連接 (1對3 我8M 另2個也是8M 一個2M  結果 8M的都正常  2M的停格. 4台電腦統一規格)
4.有些範例 都是 伺服器保持開啟    Client端都是傳送資料才連接.傳送完斷開...但我使用的方法是一但連線就不斷開
  直到 伺服器或Client端 有一端斷開連線.當然這期間我會 由伺服器每1分鐘送出1信號(以免被電信 踢線)給Client端
  .如此連接個5-6天 也不會斷線)
5.通常我寫通訊程式  不會用 127.0.0.1 來測試 .因我感覺 信號跟本沒傳送出去.最好用2台電腦連線 來測.比較準
6.傳送資料 不管是  伺服器->Client端  或 Client端->伺服器  我都是等接收端處理完接收資料.再由接收端送出一
  個信號如 "*資料OK*" 傳送端才會再傳下一筆資料(或回傳接收到的資料給傳送端比對 正確才送下筆資料)
7.相對 2 跟 6 萬一網路阻塞 又要寫一個TIME 來防呆
最後我也想請教各位大大..為何一些 tcp或udp範例  都是傳送完一筆資料後都要斷開連線.這有何好處...笨笨的我不太懂
尚請各位大大教導!!感恩

Answer 6

如果是实时收发/处理数据，拥塞是无法避免的。
彻底的方式是收发端都作为独立进程（简单点就是独立程序），并且进行数据缓冲（简单点就是直接用文件系统）。给你一个实用的方案：
§发送端
数据生成、发送为两个独立程序，约定一个固定目录做数据交换。
·数据生成程序要发送数据包时，将数据创建/写入一个不重名的数据文件 aaa.dat（aaa可以是时间、序号等），写完 aaa.dat 后再创建一个零长度的标记文件 aaa.flg。
·发送程序定时循环：确认接受端就绪，扫描数据目录，找到一个 bbb.flg 文件存在后，将 bbb.dat 的内容发送到接受端，删除 bbb.dat 和 bbb.flg，标记接受端忙。§接收端
接收、数据处理为两个独立程序，约定一个固定目录做数据交换。
·接收程序收到数据包后，将数据创建/写入一个不重名的数据文件 ccc.dat，写完 ccc.dat 后再创建一个零长度的标记文件 ccc.flg，向发送端反馈重新就绪。
·数据处理定时循环：扫描数据目录，找到一个 ddd.flg 文件存在后，对 ddd.dat 的内容进行处理，删除 ddd.dat 和 ddd.flg。以上方案为单向传送；
如果改成“数据生成/处理程序”+“发送程序”+“接收程序”就同时具有收发功能了；
如果上面再改成1:n:n的配置，那么就是能够同时响应n个请求的服务端程序了。以上方案在不同操作系统、不同开发语言下能很好地运行。