sendBuffer和sendList

gateserver下发给客户端的消息 只是放到connect的sendlist里面，然后enableMask设置为write
等到多路复用检测到他需要发的时候，可能sendlist已经有很多了个packet了
然后多路复用检测到 这个联系需要send，然后开始onSend


注意下面是核心
现在我们onSend里面要做的就是 把sendlist里面这些发出去
sendlist.pop()
写入buffer,直到sendlist为空，或者buffer满了，然后把这个buffer发送
所以有可能，一个netpacket一个包，有可能多个消息一个包，还有可能半个消息在一个包里面


而onRecv这里，客户端发来的消息，不会有多个一起发什么的，一个消息发一次，
所以收，只需要区分现在在解析头还是在解析体就行了，记住位置，即使一个netpacket
一次只到了一部分也不要紧，我只有当完整的解析出来了一个netpakcet才会
通知别人来处理 
通知谁来处理？
通知给我这个connection对应的processor
processor也是一个线程，多个connection对应一个processor，类似multiplexor
很多连接都过来消息了，push进了某个processor的messgeQueue（参见安全的消息队列）
然后processor线程，检测到里面有消息，就pop然后处理，连接消息呢，断开消息呢
还是游戏消息，游戏消息，就给server去处理，显然，这里是gateserver
gateserver收到后，呵呵，根据proc协议号的区间，判断是什么类型，往哪个server发。
比如是移动，那么就发给gameserver


gameserver收到后，知道哪个玩家要做啥，然后添加到对应player的消息队列，
player update的时候，deal这个消息。比如移动


tcpserver的recvbuffer大小和sendbuffer大小 1048576 1m
tcpclient的recvbuffer大小和sendbuffer大小 32767  31k


当multiplexor里面很多connection比如1000个，每个都有很多数据需要发送，
select epoll 的reactor模式，我们是挨个处理的，所以，很有可能轮到我这个connection
的时候，sendlist里面已经有很多很多消息了，网路游戏下行消息远大于上行，AOI嘛
如果buffer设置的小，那么一次发不完，
所以有个 检测 canNextSend，如果sendlist还没空
就继续发，直到发光为止
而onRecv就是一次ok,


onRecv就是系统层的::recv,读的内容写在recvbuffer里面，然后我解析就行了，
因为客户端发来的消息是一个个的，并不复杂

另外 写完或者发完，我并没有改变fd的状态，因为是边缘触发的，（没有设置，默认是水平触发）

否则你还得完了后改变下读写状态(这段话有问题，因为我发现写完会disableMask(write))

当发现发送完成，就会把这个写标记改为0，后面找到他就认为他不需要发，

可是奇怪的是发现读标记一直没有禁掉，因为在LT模式下，会一直读，读完为止。

写的话，写完了，手动清掉写标记，后面就不会触发写