Mina-1

青旅半醒 2022-01-09 22:21 190阅读 0赞

客户端，服务端几乎对等，一个主selector（单个线程，Acceptor线程，Connector线程）和多个幅selector（多个Processor线程）  
服务端Acceptor线程：很明显处理bind，unbind，和accept连接，像bind,unbind通过future，队列可实现异步，但这里并没有开放，如下

protected final void unbind0(List<? extends SocketAddress> localAddresses) throws Exception {
        AcceptorOperationFuture future = new AcceptorOperationFuture(localAddresses);
    
        cancelQueue.add(future);
        startupAcceptor();
        wakeup();
    
        future.awaitUninterruptibly();
        if (future.getException() != null) {
            throw future.getException();
        }
    }

客户端Connector线程：处理新的connect请求，处理已经建立的连接（select得到），处理超时连接。  
connect过程虽短暂，但也要耗部分时间，对于在非阻塞模式下可立即建立的连接（connect()返回true）  
，不需要过此线程处理

Processor线程：处理新建立的连接（注册到幅selector关注读事件，SessionCreated，SessionOpened事件）  
处理连接事件：Read，Write（把连接即session放入flushingSessions，这个地方很特殊，下面介绍）  
flush：flushingSessions内的连接，把每个连接需要写的数据都写出，messageSent事件  
移除连接：解除注册，关闭连接，一般都是内部发生读写错误才将连接放入移除列表

读是被动的，写是主动的，写的情况比较复杂  
一般客户端先主动发起写调用session.write()  
客户端线程：从TailFilter到HeadFilter一直传递filterWrite事件，在HeadFilter处将WriteRequest放入连接的WriteRequestQueue，并把连接放入flushingSessions，注意我们要加一个ProtocolCodecFilter，保证WriteRequest内放的是IoBuffer，而不是你写的原始对象。  
Processor线程：上述flush操作，flush只能处理ProtocolCodecFilter里生成的IoBuffer  
服务端接收消息：Read事件，messageReceived事件，IoHandler处可session.write()写回应答

上述情况，没有关注Write事件，但当我们flush时，数据可能只写了一部分或写不出去（如TCP的发送缓冲满了），那我们就关注Write事件，当再次可写的时候（如发送缓冲有空间），再连接放入flushingSessions，再次flush  
我们flush时，限定了单个连接单次flush的大小上限，如果超过了连接放入flushingSessions，下次再flush

每个session都会创建一个默认的自己的FilterChain，内含自己的HeadFilter和TailFilter，自己可向FilterChainBuilder  
加入一些IoFilter，各session的FilterChain内含的都是同一加入的IoFilter对象  
为支持双向链表，某些事件tail传到head（只有filterWrite和filterClose），某些head到tail(所有其它事件)，每个链表节点Entry  
含IoFilter和NextFilter，NextFilter封装了针对每种事件寻找下一个Entry的逻辑（是next还是prev）

TailFilter对由HeadFilter传过来的事件一般交由IoHandler处理，我们需编写IoHandler定义业务逻辑