回想一下,现在程序进行到什么状态? 看上图的subReactor每一个蓝色的箭头都是一个客户端的channel, 问题是netty还处理不了这些channel上的会发生的感兴趣的事件,因为第一步我们只是把jdk原生的chanel和原生的selector之间进行了关联, 而netty对他们的封装类还没有关联,于是下一步就通过传播active的行为去二次注册关联感兴趣的事件
关于pipeline中的事件传递太多内容了,在下篇博客中写,连载
现在直接给结果,
传递到header的read()源码如下
@Override public void read(ChannelHandlerContext ctx) { // todo 如果是服务端: NioMessageUnsafe // todo 如果是客户端: NioSocketChannelUnsafe unsafe.beginRead(); }接着跟进
@Override protected void doBeginRead() throws Exception { // Channel.read() or ChannelHandlerContext.read() was called //todo 如果是服务端: 这里的SelectionKey就是我们在把NioServerSocketChannel 注册进BoosGroup中的eventLoop时,返回的selectionKey , 就在上面 //todo 如果是客户端: 这里的SelectionKey就是我们在把NioSocketChannel 注册进BoosGroup中的eventLoop时,返回的selectionKey , 就在上面 final SelectionKey selectionKey = this.selectionKey; // todo 这SelectionKey 就是我们把 NioServerSocketChannel中的ServerSocketChannel注册进BossGroup时, 附加的第三个参数 0 if (!selectionKey.isValid()) { return; } readPending = true; // todo 获取这个Selection 的感兴趣的事件,实际就是当时注册时的第二个参数 0 final int interestOps = selectionKey.interestOps(); // todo 如果是服务端, readInterestOp是创建服务端channel时设置的 op_accept // todo 如果是客户端的新连接,readInterestOp是创建客户端channel时设置的 op_read if ((interestOps & readInterestOp) == 0) { // todo interestOps | readInterestOp两者进行或运算,原来是0事件 , 现在又增加了一个事件, accept事件或者是read // todo 进而 从新注册到SelectionKey上面去。。。 0P_Accept 或者 OP_Read selectionKey.interestOps(interestOps | readInterestOp); } }ok, 到这里netty的新链接接入就完成了....
连载下一篇, pipeline中的事件传播