TCP 性能问题 about cellnet HOT 10 CLOSED

1. 小包问题，你说的是类似MMO里的网关合包么？ 这个在服务器之间做会影响实时性能吧？
2. WriteFull这个有具体测试数据或者文章依据？
3. v3版本有这个功能，稍后会添加回来。顺便问下，如果逻辑层有心跳，socket超时设多大合适？

from cellnet.

另外，读超时这个我没打算设置。游戏服务器一般在逻辑层都有心跳。自定义的心跳包在安全性上比读超时安全一些，随便发一个包就能让读超时失效，但心跳包可以自己加密。

from cellnet.

发送缓冲区满了会阻塞在Write(): 写超时应该设置一下
我对golang的同步编程感觉到头痛，原因如下：
1.实际测试的时候发现，在windows上面发送缓冲区最小为640K，也就是正常情况下对端不接收数据也要很久才能反应过来。
2.对于业务逻辑层发送数据，如果做成直接调用Write的话，如果缓存区满了会阻塞，如果在业务层就会影响业务逻辑，所以只能做在单独的协程里面。
3.对于发送数据，应该是以现有缓存的数据大小为准，不应该以包的数据为准。比如说：发送队列里面有10个数据包，那么上次Write完成之后应该把这10个包打包成一个[]byte,然后发送出去

from cellnet.

如果按照你说的写超时就算错误的话，很容易丢包。
有人使用cellnet时，说也会有你说的这样情况，但是因为cellnet的发送队列不是用channel做的，不会阻塞，只会慢慢发出去，只是消耗一点内存而已。
同步异步都无法解决io发送不过来的问题

from cellnet.

不是，写超时意味着发送缓冲区满了，也就是说对端没有接收，这个情况要么网络出问题了，要么是恶意攻击，应该直接Close()。
我还没用过cellnet.只是从golang的尿性上面来说的，好的框架确实不能用channel. channel会造成阻塞。
所以发送数据的正确姿势应该是用mutex+slice ,但是在发送的位置应该是slice里面有多少发送多少，而不是一个一个发。通常这种方式有两种做法：
1.在发送的goroutine里面分配一个固定大小的buf，专门用来发送。发送队列数据取完或者固定大小buf满了就发送出去。但是这样发送地方逻辑就要复杂一点。
2.所有包直接append,然后发送出去。这么做GC压力大，但是逻辑简单

所以建议第1种方式
个人测试情况来看，系统发送缓冲区用默认值的话，写超时1秒不能再多了。现在操作系统的读写缓冲区都是动态扩张的。反正我的win10设置640K以下没用，都会扩张到640K.设置超过640k.那么才会是设置的值

from cellnet.

服务与服务之间一个包一个包的发送，怎么能高效？
我看了大量golang TCP 的网络库。有的发送是用一个小的channel（make(chan xx ,100)）,channel满了就直接关闭，有些是直接Write() .感觉都不靠谱

from cellnet.

从需求出发优化，我只做设计，剩下的想优化自己来，满足特殊需求就是了。做到极端优化也是有缺点的，凡事都不是完美的

from cellnet.

GC问题，内存池直接搞定。P.S. go有逃逸检测，有了解过？C#都没这个高级的东西，优化C#网络库比C++都累。
烦请用下cellnet再来说问题。 cellnet发送队列本身就是用slice+condition做的。直接避免了发送阻塞问题。
发送阻塞，不是对端没收，只是收不过来而已。一般只是暂时问题。直接Close了，到时候查bug可以查到人崩溃。你看操作系统层给你分配内存，是不是你要求很大的内存觉得不应该分配就直接把你关了？同理，作为底层，任何的莫名close都会非常麻烦。发送队列占用内存大，检测系统报出来，查下对端问题就好了。

写网络库谈windows。。这个没啥意义

from cellnet.

只能说比其他的框架好点，用channel来做的，都能算是一个bug了。如果不算成bug的话，那样的框架只能做小项目或者单机版，等我空了我来提PR

from cellnet.

我知道你这个是slice+condition，你没明白我的意思。我只是建议发送的时候组合一下包，别一个一个发送就行了

from cellnet.