- 主题:请教两个二级指针的问题
这个版叫程序设计
不叫特快
问题摆在这里，对方发过来包头的长度值是1g
你打算怎么收这个数据？
【 在 flw 的大作中提到: 】
: 私域系统，没那么多弯弯绕绕，
: 我们要学会包容。
: 工程上的事儿，能跑就行。
: ...................
--
FROM 39.144.251.*
tcp和上层怎么处理数据没关系
【 在 ylh0315 的大作中提到: 】
: 代码要省好多事呀，不必特别检查数据长度。小于0错误，仅此而已。
: 也不允许超长过2g的。因为确实不知道用户需要传多大数据。大数据自动分段的问题，交给TCP吧。我省事了。
--
FROM 39.144.251.*
对方发一个包，你这里就申请了2个g
不说对方故意攻击你，如果他的网络特别慢，你这2g要持有很长时间
【 在 ylh0315 的大作中提到: 】
: malloc。失败后返回系统错误，错误号是内存分配失败。
: 导致这一个操作失败。没有大的影响。连接都不会挂断。
: 这个歪楼就是从malloc开始的。
--
FROM 39.144.251.*
malloc 然后接收呀。内存不够用 mmap 也可以的呀。
再原始一点，分片收到文件里，然后走 IO seek 呀。
封闭系统里面，对方想发 1g，那肯定是有 1g 的理由呀。
你有能力收你就收，你没能力收你就报错误码，多正常的事儿。
FTP 不就这么干的吗？
难道超过 1G 的文件就不下载了？
HTTP length 就不支持大于 1G 的长度了？
别老是一惊一乍的，把通讯对端当仇人可不好。
是不是警察上门你还要看警号呀？
所有的系统设计都有个前置条件，他的系统在他的前置条件下，
工作了都几十年了，你现在非要说他有问题，也不知道是他欠你的，还是你欠他的。
【 在 slowaction 的大作中提到: 】
: 这个版叫程序设计
: 不叫特快
: 问题摆在这里，对方发过来包头的长度值是1g
: 你打算怎么收这个数据？
--
FROM 163.125.197.*
这里面说怎么处理长数据包
和tcp以及mtu一点关系没有
【 在 ylh0315 的大作中提到: 】
: 是的。可是我上层怎么处理数据跟下层有关系。
: 考虑到下层的性质才上层才这么处理的。
:
--
FROM 39.144.251.*
你这对网络是分层的这事一点概念没有
根本不需要管tcp分段的事，你也管不了
你总惦记他干什么
【 在 ylh0315 的大作中提到: 】
: 就是靠TCP按MTU自动分段呀，难不成我自己分段吗？那多麻烦。人家有这功能为啥不许我用呢？
: 这逻辑怎么就说不通呢？
--
FROM 39.144.251.*
说的是你会长期占用2g的内存
而对方只发了一个数据包头过来
【 在 ylh0315 的大作中提到: 】
: 那是它的事。他要发1g怎么都快不了。
: 弄不死我不就得了，其他问题他自己想办法解决。
: 没有安全问题。
--
FROM 39.144.251.*
你怎么发包，和滑动窗口没有直接关系
不存在发小包就用不上滑动窗口这回事
【 在 ylh0315 的大作中提到: 】
: 我用它就可以啦，发大包啊，让它破成小包呀。
: 太小的包，没法发挥滑动窗口的作用。
: 你那个8k的tls，人家给我一个100k的数据，我怎么办呀？我来破包，麻烦不麻烦呀！你愿意做你做，反正我不做。
: ...................
--
FROM 110.87.77.*
首先，滑动窗口大小和报文大小没有关系
其次，send次数也和网络包数没有关系
【 在 ylh0315 的大作中提到: 】
: 你8k小包了，一共没几个报片，怎么滑动？
: 缺省8片，至少12k。13.5k才滑一步。
--
FROM 110.87.77.*
你这段全错
当然不用等
当然和包没关系
【 在 ylh0315 的大作中提到: 】
: 它不是在一个大包里组织滑动窗口吗？跟别人能混合编组吗？
: 基本原理是在一个报文里分报片组织滑动窗口，没办法跨报文滑动吧。
: 不是send一次一个报文吗？可能有报文收集功能，0.几秒内的报文可以合并。
: ...................
--
FROM 110.87.77.*