winsock能一次接收的一个数据包最大是多少?

ltz 2000-09-05 04:53:00
...全文
974 27 打赏 收藏 转发到动态 举报
写回复
用AI写文章
27 条回复
切换为时间正序
请发表友善的回复…
发表回复
Wilbur 2000-09-10
  • 打赏
  • 举报
回复
你知道你分配了多少内存吗?
你可以在你的机器上做实现, 开始分配 2 字节, 成功则加倍, 最后就知道可以分配多大的内存了.

由必要一次接收几兆的数据吗? 如果采用 blocking 方式不是全部阻塞在那里了.
xzou 2000-09-10
  • 打赏
  • 举报
回复
不好意思,服务器总报错,多发了几次.
xzou 2000-09-10
  • 打赏
  • 举报
回复
我定义了一个char(99999999)想用recv()一次接收一个可能很大的文件,但报了缓冲区溢出,请问诸位VC里能申请的缓冲区最大是多少,unix下c又是多少?winsock中能否一次接收几兆的包?希望大家帮一下手.
alstamania 2000-09-08
  • 打赏
  • 举报
回复
TCP是保证完整性和顺序性的。为你所谓的包加个头用来记录后面数据的长度就完了嘛!第一次收到先得到长度,计算收到的数据是否在这次调用都收到了,若没收完,存起来再等嘛!
maptrix 2000-09-07
  • 打赏
  • 举报
回复
在传送大数据的情况下,各个数据包很有可能不按顺序到达,不过这没什么,因为TCP/IP协议是在很早就实现了,那时的网络状况是非常差的,而且他的级别是要在核战争后依然可以使用,所以对数据传输、就错等考虑的很成熟了。
网络状况不好、或在数据包丢失后,发送端会再次尝试发送,这就有可能造成数据包非顺序到达,而且各IP包甚至都有可能不通过相同的网关到达目的地,也有可能造成数据包的非顺序到达,但他们在数据包的头数据中记录了整个数据包的情况,即使非顺序到达,也能组成最终的数据包。
在整个网络的状况非常恶劣的情况下,有可能会造成整个数据包的重新发送,或者整个数据包的丢弃,这都是有可能的!但协议已经非常完善了,所以你不用太担心这些细节!
Wilbur 2000-09-07
  • 打赏
  • 举报
回复
ltz

问出这样的问题, 还是没有理解流的概念....
我们用 C++ 中的概念解释: C++ 中也有很多数据流的东西, 如 iostream, fstream, strstream, 你在用他们的时候有没有想过用 fstream 写数据到文件或从文件读数据的时候, 这些数据是分多少次写完或读完的呢? 你可以一次读 12K 字节的数据, 也可以分 12K 次去读 12K 字节的数据.

你可以想象 TCP/IP 协议就如同两台机器之间的管道, 数据就是通过这个管道的水流.

具体来说, 12K 的东西, 你可以一次接收, 也可以分成你喜欢的任意次来完成. 如果在一端发送了 12K 的东西, 那么另外一端收到的东西肯定是正确的(其实TCP协议也只承诺这个).
Again 2000-09-07
  • 打赏
  • 举报
回复
关注
ltz 2000-09-07
  • 打赏
  • 举报
回复
?????????????????????高手,能否再问一下,服务器发送大数据包(比如12K),客户端可能要分几次才能收完这个数据包,我应该怎样判断这几次收到的数据都属于同一个包?????
shines77 2000-09-07
  • 打赏
  • 举报
回复
ltz

如果像你说的那样的话,那还叫什么按顺序无丢失的到达啊,前提是TCP/IP流式套接字,不信,你可以定制一串特殊的数据验证一下,流式.....解释了那么多遍了,口水都干了:-))。
sweet 2000-09-07
  • 打赏
  • 举报
回复
如果套接口是数据报类型,接收到的数据报顺序有可能会跟发送方的顺序不一致,
而且可能丢包。如果是流类型,顺序肯定是一制的。
ltz 2000-09-07
  • 打赏
  • 举报
回复
再问您以下:如果A连续发送两个数据包A1、A2;它们的分包A11、A12.......A21、A22、A23....有没有可能交叉到达,比如按此顺序:A11、A12、A21、A13、....
shines77 2000-09-07
  • 打赏
  • 举报
回复
lbz

我懂你了的意思了,你是说怎么检测你每次发到client的包,虽然他可能会被分为好几块,但你在cilent端却想把它识别出来归为一个数据包内,说了那么多,原来是这样,这样很简单啊,你可以在Server端发送数据包的时候头和尾做一个标识,如你要发12K的数据,我先在12K数据的前面叫上"<--!", 后面加上"-->",然后在client端接受的时候,判断数据包开始和结束的位置,把数据包区别开来,当然头尾的标识你自己可以随意的定,但最好不要跟发送的数据有冲突,而且也不要太长,以节省发送的数据长度。

好了,说了这么多,不知道合不合你的意思....
Wilbur 2000-09-07
  • 打赏
  • 举报
回复
补充, 上面说的比较偏向 blocking 模式(每次接收2K, 或3K), 若采用 non-blocking 模式, 你可能收到的不是这样等大小的. 但是无论 blocking, 还是 non-blocking 模式, 都是数据流的方式.
Wilbur 2000-09-07
  • 打赏
  • 举报
回复
也许是一觉醒来, 迷迷糊糊地不明白你的问题. 我可以这样假设你的问题:
有 A, B 两端(我不想叫服务端和客户端), 已经建立连接等等, 只等着发送数据了. 现在 A 发送了 A1(8K), A2(4K) 的数据给B. 这个时候, B 早已经等着 A 发送的数据, B 比较心急, 所以希望能每次到达 2K 数据就被叫醒一次(不象我刚才的睡觉, 每次是希望到达 1kkk 才醒来), 那么 B 收到的数据是 B1, B2, B3, B4, B5, B6 . 那么有这样的等式:
A1 = B1 + B2 + B3 + B4; A2 = B5 + B6;

可是世界上怎么有这么好的事情, B 这次设置为收到 3K 才被叫醒, 那样收到的数据是: B1, B2, B3, B4, 那么 A1 = B1 + B2 + B3(前面的2/3); A2 = B3(后面的1/3) + B4;

从后面的设置(3K)可以看到, 数据就是以流的方式传输的.

不知道我的假设是否是你的问题.
ltz 2000-09-07
  • 打赏
  • 举报
回复
请继续关注!!!!!!!!!
ltz 2000-09-07
  • 打赏
  • 举报
回复
Wilbur老兄:谢谢您;
我的意思是这样的:比如server连续发送了两个大的数据包,但由于带宽原因,client可能要分多次(比如七次)才能收完这两个数据包,即client端要激发其次FD——READ事件,我的疑问是怎样判断每个事件是由哪个数据包激发的。当然,我相信两个数据包都能安全按顺序到达client断,但这跟确定每个小包的归属是两回事?
Wilbur 2000-09-06
  • 打赏
  • 举报
回复
TCP 是面向数据流的传输方式, 可是很多人不理解这句话...........
mpatrix 的解释是正确的.

大家如果不是以这样的观点来考察 TCP协议, 编程的时候很容易出问题, 原因很简单, 协议不是按照你设想的方式工作.

不用担心丢包, TCP协议可以保证数据按顺序正确地传输, 具体如何保证我就不想讲了.

题外话, 大家开辟缓冲区的时候, 没有必要每次开辟一点点小空间, 然后释放, 这样很容易导致内存的碎片化. 很可能导致系统还有足够内存, 可是你去分配内存的时候发现不能成功. 这不能怪操作系统, 因为无论采用何种内存分配策略, 都挡不住这样的操作.
shines77 2000-09-06
  • 打赏
  • 举报
回复
数据报(UDP)默认是8192,
流式套接字(TCP/IP)就像Wilbur说的一样,可以保证数据完整的按顺序的发送,所以不必担心丢包。

UDP是使用sendto()函数的,此函数对发送数据大小有限制,不应超过底层网络支持的最大数据包的大小,而此大小可以用WSAStartup()调用返回。

TCP/IP是没有限制的,其使用send()函数。现在清楚了吧:)
luxes 2000-09-06
  • 打赏
  • 举报
回复
如果是基于数据报,
用套接字选项测试一下:
int size;
isize=sizeof(size);
getsocketopt(s,SOL_SOCKET,SO_MAX_MSG_SIZE,(char *)&size,&isize);
ltz 2000-09-06
  • 打赏
  • 举报
回复
各位高手,我是这个意思:我要接各种类型的大小不同的数据包数据,我不知缓冲区要开多大,太大了浪费,太小了又丢包,是否对所有数据均采用一个最大的缓冲区?
加载更多回复(7)
WinSock Expert v0.6 beta1 运行于Win9x/2k/nt 作者:董雪强 email:dxqsoft@sina.com http://www.dxqsoft.com 一、版本历史 ……v0.6 beta1 调整了Filter的过滤功能,可以支持模糊的规则设置。 例如:可以使用FF ?? 3F ?? ?? 34 1A ...... 这样的过滤条件。 其他一些改进。 ……v0.3 beta1 新增了以不同颜色区分接收和发送的数据包。 修正了接收数据包时可能出现错误信息的问题。 修正了数据包显示在HEX模式下,无法正确显示相应文本内容的问题。 设置为一打开一个进程就立即开始捕获数据包。 ……v0.2 beta1 第一个发布的版本。 二、简介 这是一个用来监视和修改网络发送和接收数据的程序,可以用来帮助您调试网络应用程序,分析网络程序的通信协议(如分析OICQ的发送接收数据),并且在必要的时候能够修改发送的数据。 目前软件为测试版本,作者无法保证程序不会出现任何的错误,对本程序造成的任何问题作者不负任何责任,您必须同意此项才能使用本软件。 由于软件还处于测试阶段,没有写出详细的使用手册,大致上的使用方法和WPE类似,在这里我只能简单介绍一下使用中的注意事项,希望能对你的使用有帮助,如果您在试用中有什么问题请通知我,以便我不断改进,有好的技巧和方法也希望能告诉我,好让我编写帮助文档,或者,如果愿意最好能帮我编写帮助文档 :) 。 三、注意事项 1、首先运行本软件和需要监视的网络应用程序,然后使用"Open Process"按钮,选择正确的程序打开,这时候会创建一个子窗口,使用同样的方法您可以同时监视多个进程。 2、默认情况下,刚刚打开的进程已经开始监视数据,需要的话您可以手动按下工具条上的"Start/Stop Capture" 按钮进行监视/不监视的切换,如果发现一开始没有自动进行监视,您也需要手工进行切换。 3、使用"add filter","Edit Filter"等可以添加/修改筛选条件,这可以用来自动修改应用程序向外发送的数据,具体使用方法和WPE的类似。 4、创建好筛选条件后,您需要按下"Set Filter"按钮进行设置应用,否则这些筛选条件不会起作用。 5、在筛选列表上的右键菜单中您可以保存/装载筛选条件。 6、通过"Change Packet View"按钮您可以切换数据包的显示方式:文本方式和十六进制方式。
WinSock Expert v0.7 运行于Win9x/2k/nt 作者:董雪强 email:dxqsoft@sina.com http://www.dxqsoft.com http://bbs.dxqsoft.com 一、版本历史 ……v0.7 (2010.7.2) 支持Vista/Win7。 为获得更好的兼容性,需关闭Vista/Win7的UAC功能(但会降低系统安全性),否则部分程序可能无法截取数据包。 ……v0.6 beta1 调整了Filter的过滤功能,可以支持模糊的规则设置。 例如:可以使用FF ?? 3F ?? ?? 34 1A ...... 这样的过滤条件。 其他一些改进。 ……v0.3 beta1 新增了以不同颜色区分接收和发送的数据包。 修正了接收数据包时可能出现错误信息的问题。 修正了数据包显示在HEX模式下,无法正确显示相应文本内容的问题。 设置为一打开一个进程就立即开始捕获数据包。 ……v0.2 beta1 第一个发布的版本。 二、简介 这是一个用来监视和修改网络发送和接收数据的程序,可以用来帮助您调试网络应用程序,分析网络程序的通信协议(如分析OICQ的发送接收数据),并且在必要的时候能够修改发送的数据。 目前软件为测试版本,作者无法保证程序不会出现任何的错误,对本程序造成的任何问题作者不负任何责任,您必须同意此项才能使用本软件。 由于软件还处于测试阶段,没有写出详细的使用手册,大致上的使用方法和WPE类似,在这里我只能简单介绍一下使用中的注意事项,希望能对你的使用有帮助,如果您在试用中有什么问题请通知我,以便我不断改进,有好的技巧和方法也希望能告诉我,好让我编写帮助文档,或者,如果愿意最好能帮我编写帮助文档 :) 。 三、注意事项 1、首先运行本软件和需要监视的网络应用程序,然后使用"Open Process"按钮,选择正确的程序打开,这时候会创建一个子窗口,使用同样的方法您可以同时监视多个进程。 2、默认情况下,刚刚打开的进程已经开始监视数据,需要的话您可以手动按下工具条上的"Start/Stop Capture" 按钮进行监视/不监视的切换,如果发现一开始没有自动进行监视,您也需要手工进行切换。 3、使用"add filter","Edit Filter"等可以添加/修改筛选条件,这可以用来自动修改应用程序向外发送的数据,具体使用方法和WPE的类似。 4、创建好筛选条件后,您需要按下"Set Filter"按钮进行设置应用,否则这些筛选条件不会起作用。 5、在筛选列表上的右键菜单中您可以保存/装载筛选条件。 6、通过"Change Packet View"按钮您可以切换数据包的显示方式:文本方式和十六进制方式。

16,471

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧