错误的理解

ChannelInboundHandlerChannelOutboundHandler,这里的inbound和outbound是什么意思呢?inbound对应IO输入,outbound对应IO输出?这是我看到这两个名字时的第一反应,但当我看到ChannelOutboundHandler接口中有read方法时,就开始疑惑了,应该是理解错了,如果outbound对应IO输出,为什么这个接口里会有明显表示IO输入的read方法呢?

正确的理解

直到看到了Stack Overflow上Netty作者Trustin Lee对inbound和outbound的解释,疑团终于解开:

众所周知,Netty是事件驱动的,而事件分为两大类:inboud和outbound,分别由ChannelInboundHandlerChannelOutboundHandler负责处理。所以,inbound和outbound并非指IO的输入和输出,而是指事件类型。

那么什么样的事件属于inbound,什么样的事件属于outbound呢?也就是说,事件类型的划分依据是什么?

答案是:触发事件的源头

继续阅读

随意记录学习netty的过程中遇到的大大小小的问题和思考。

如何理解inbound和outbound?

EventLoop的epoll实现为什么要使用timerfd?

epoll_wait的函数原型:

int epoll_wait(int epfd, struct epoll_event *events,
                      int maxevents, int timeout);

Netty为什么不使用epoll_wait自身提供的timeout参数,而是使用timerfd来控制epoll_wait的超时呢?

原因参见这次提交的comment:Unify KQueue and Epoll wait timeout approach

即:

  • timerfd(内核timer对象,纳秒级超时)可以提供比epoll_wait(毫秒级超时)更细粒度的超时控制。
  • 与EventLoop的KQueue实现保持一致。

Netty 4 线程模型

最近的工作中用到了WebSocket协议,研究了下它的数据帧格式,发现其payload length的表示方式很适合用来优化以前用到的网络库。

简单来说就是把固定4字节表示包大小的方式,改为用可变字节数表示包大小,大部分包的大小可以用1个字节表示,可表示的大小范围为0 ~ 253字节,稍微大点的包用1+2字节表示,大小范围为0 ~ 64KB,再大的包才用1+3字节表示,大小范围为0 ~ 16MB。对于游戏来说,16MB的包大小足够用了。如果不够,也是有对策的。

先来看下WebSocket的数据帧格式。

WebSocket数据帧格式

RFC 6455 给出了 WebSocket 协议的详细规范,其中第5.1节说到,在WebSocket协议中,数据是使用一系列frame来传输的,随后5.2节详细介绍了frame的格式:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+
继续阅读