- 主题:请教两个二级指针的问题
应用层分包不是为了tcp
本来这事和tcp一毛钱关系也没有
也不存在什么8k的包会比100k慢的事
【 在 ylh0315 的大作中提到: 】
: 就是。用户给我多大，我就扔给TCP多大。大小的事，不归我管，让TCP去分吧。
--
FROM 39.144.251.*
网络能不能跑满，
看你单位时间给了多少数据
而不是看你调用了多少次每次多少
这是很简单的逻辑
【 在 ylh0315 的大作中提到: 】
: 每次send的数据太少，根本就占不满网络，你测一下吧。
: 我做的是交易中间件，基本一问一答，一个远过程调用完成一个交易，一个交易会产生大量数据。这跟你的应用场景不同，进一步争论没有太大意义。
--
FROM 39.144.251.*
因为你怎么发，他都能过去
你画蛇添足搞个mtu的判断，他当然能过去了
【 在 ylh0315 的大作中提到: 】
: 查了下，MTU自己处理的，自动分片。试验过，有效。能够通过糟糕的路由器。
: int SendNet(int socket,char *buf,int n,int MTU)
: {
: ...................
--
FROM 39.144.251.*
你说的mtu到底是什么，你自己都倒腾不清楚
有什么可讨论的
【 在 ylh0315 的大作中提到: 】
: 没有这个MTU，当年真过不去，要么凭啥画蛇添足。
: 不过此MTU非彼MTU，它恰恰破坏了滑动窗口，造成慢。
: 假如MTU设成8k，就成了你的。就可以见证用你的限制传输得多慢。
: ...................
--
FROM 39.144.251.*
就凭你这 此mtu不是彼mtu
我都不知道你说的到底是什么
你要讨论问题，请用标准技术语言
【 在 ylh0315 的大作中提到: 】
: 我说的很清楚了，起不一样的作用。
: 我的那个，恰恰是你说的，（你要限制报文，比如说到8k），限制了报文的大小，没有改变报片的大小。
: 所以这个系统完全能实现你的要求。
--
FROM 117.30.164.*
讨论了几十页，现在你说mtu不是tcpip里面的mtu
那你说的8k是哪里的8k
你说的滑动窗口是建材市场的滑动窗口么
【 在 ylh0315 的大作中提到: 】
: 前边跟你讨论时我都忘了，后来翻了下程序，发现不对了，你说的要求我都已经实现了。程序里的MTU是报文长度。可以设置成你说的8k。不过传输速率会很慢。
: 如果信道允许，还是不设置为好。
: 结论是，传输工具不限制报文尺寸最好。
: ...................
--
FROM 110.87.76.*
好像不知道tls是什么
在这里讨论协议安全，这太好笑了
【 在 ylh0315 的大作中提到: 】
: 前边跟你讨论时我都忘了，后来翻了下程序，发现不对了，你说的要求我都已经实现了。程序里的MTU是报文长度。可以设置成你说的8k。不过传输速率会很慢。
: 如果信道允许，还是不设置为好。
: 结论是，传输工具不限制报文尺寸最好。
: ...................
--
FROM 117.30.164.*
线路MTU
滑动窗口大小或者发送缓冲区大小
协议包大小
每次send的大小
这是4个独立的东西，可以有不相等的4个值
你理解成一个值，在网络领域绝对是卧龙凤雏级别的
请把基本概念倒腾清楚在讨论问题
【 在 ylh0315 的大作中提到: 】
: 我说的8k是你说的8k，就是报文长度。
: 这个报文尺寸，到了底层就无法滑动。
--
修改:slowaction FROM 117.30.164.*
FROM 117.30.164.*
有什么关系？
mtu和那三个值有什么关系？
你这大包说的是应用层 协议层 网络层，哪个层上的大包
说个问题，恨不得把所有知道的名词都扯进来
【 在 ylh0315 的大作中提到: 】
: 但是这几个是有关系的，最后体现在性能上。
: 回归主题，大包传输没有安全问题和效率问题。
: 整体方案经验证，可行。
--
FROM 39.144.251.*
问题是从来没有人说应用层大包如何
你对着应用层的大包发表一通意见，你自言自语么
【 在 ylh0315 的大作中提到: 】
: 我说的大包，是应用层的。
: 我提供的中间件，是第5层，RPC，远过程调用。也叫报文层。
: 我的工具支持用户提供的大包数据。
: ...................
--
FROM 110.87.76.*