- maps Java NIO operations (OP_READ, OP_WRITE etc) mapping to Grizzly IOEvent
- maps Java NIO SelectionKey to Grizzly Connection ?
SelectorHandlerimplements thread-safe logic for registering/de-registering
SelectableChannels on Selectors, changing SelectionKey interests, executing custom tasks in Selector threads (to avoid unexpected locks)
? Connections
在上图中，可以看出Connections是怎样和Transports发生关系的，以及基础的Connection抽象。在Grizzly 2.3中有TCP和UDP连接实现，除此之外，we have special server-Connections for both TCP and UDP.
*TCPNIOServerConnection的工作方式同TCP ServerSocket，它会绑定到特定的TCP
host：port，监听来自客户端的TCP连接。当有新的TCP连接接入就绪，TCPNIOServerConnection接入该连接，根据Transport设置，配置一个新的连接。
*UDPNIOServerConnection代表一个UDP连接，它不绑定到任何特定的地址，因此可以接收所有的发送到该地址的UDP包。换句话说，UDPNIOConnection和UDPNIOServerConnection的唯一区别就是，后者不会绑定到任何地址。
*Processor.逻辑部分，负责处理Connection NIO事件(ACCEPT, CONNECT, READ, WRITE, CLOSE)
*SelectionKey. The Connection underlying java.nio.channels.SelectionKey, which defines the NIO SelectableChannel<-> Selector registration.
? Establishing client connections
ConnectorHandler API负责建立和初始化客户端连接。
如上图所示，TCPNIOTransport和UDPNIOTransport实现了SocketConnectionHandler接口，因此可以直接使用Transport实例创建新的客户端连接：
在这个例子中，新创建的客户端连接源自Transport’s Processor。也可以创建自定义的ConnectorHandler(UDP和TCP传输类似)：
下边两序列图将说明异步连接操作：
第一个图中，异步连接传到当前线程，然后调用ConnectorHandler.connect(…)操作，返回get Future
上边代码中，只是将connection对象添加到了SelectorRunner的队列中，然后在selector-thread中作处理。在selector-thread中，连接实际是注册在了SelectorRunner关联的
Selector上，一旦注册成功，SelectorRunner通知ConnectorHandler注册完成，然后进行一下操作：
* for UDP transport—UDPNIOConnection被初始化。Processor接到CONNECT操作完成的通知，然后Future
* forTCP transport–需要等待底层操作系统网络框架通知框架，Connection已经连接到目标地址(UDP没有这个)，这有这时Processor才接到CONNECT操作完成的通知，然后Future
对于TCP传输，在服务器端TCPNIOServerConnection接受新的客户端连接。这时处理逻辑就很像上图，但不是”CONNECT”，而是将发生在TCPNIOConnection上的”ACCEPT”事件通知Processor。
1.4 FilterChain and Filters
FilterChains and Filters
上一章讨论了Processor，它的功能是处理Grizzly*Connection*s上发生的I/O事件。FilterChain是在Grizzly中使用的最有用的Processor。
FiterChain，顾名思义，是一个*Filter*s的处理链。每个Filter是一个待执行的processing work unit，其目的是检查 and/or 修改FilterChainContext代表的事物的状态。
To give an idea how FilterChain may look like, here is example of FilterChain, which implements HTTP server logic:
* TransportFilter负责从网络连接读取数据到缓冲区，以及将缓冲区的数据写回网络连
接。
* HttpFilter负责Buffer<-->HttpPacket转换(双向)
*HttpServerFilter负责处理请求*HttpPacket*s和生成相应*HttpPacket*s，and send them
back on FilterChain in opposite direction (HttpServerFilter->HttpFilter->TransportFilter). So, what if we want to implement HTTPS server? It’s simple:
添加一个SSLFilter，负责编码/解码SSL secured data。
正如我们所见，在任意的I/O事件处理期间，FilterChain链中的Filters会依次执行。重点：大多数I/O事件处理都是从第一个Filter开始，到最后一个Filter结束(上图中从左至右)，除了WRITE事件，它是从最后一个Filter开始，到第一Filter结束(从右向左) 为了更清楚描述问题，下边将定义一些术语：
* Upstream–从链中的某个Filter到最后一个Filter(上图中从左到右) * DownStream–从链中的某个Filter到第一个Filter(上图中从右到左)
让我们看下FilterChain可以处理哪些I/O事件，为此我们可以看下Filter接口的方法：
所以I/O事件有：
* READ：Connection中数据已就绪，等待读取和处理
* WRITE：准确写数据到Connection，Filter可负责转换数据表现形式，例如上图
中HttpPacket->Buffer
* CONNECT：新的客户端Connection已连接 * ACCEPT（TCP only）：新的客户端Connection已被服务器
Connection(TCPNIOServerConnection)接受。
* CLOSE：连接已关闭（either locally or by peer） 重点：特定Connection上的相同事件是连续地执行的。例如，如果我们在Connection “A”上处理READ I/O事件，Grizzly将不会在Connection “A”上开始其它READI/O事件，直到之前的READ I/O事件处理完毕。如果用户决定管理I/O事件处理，那么让然需要关注连续事件处理的“规则”。
此外，FilterChain的Filters还可以初始化和处理自定义事件通知。The event initiator may choose to emit the event upstream or downstream by FilterChain like:
FilterChain中的Filters可以通过实现handleEvent方法来拦截和处理自定义事件：
如我们所见，每个Filter “handle”方法都有一个FilterChainContext参数，并且返回一个NextAction结果。
