起因
最近由于工作需要通信功能，我就上午搜搜大厂都在用用什么通信框架，在java领域netty是相当火的一个通信框架，于是我就在github上找到了C#版本额netty框架---DotNetty。
DotNetty
DotNetty是微软的Azure团队，使用C#实现的Netty的版本发布。不但使用了C#和.Net平台的技术特点，并且保留了Netty原来绝大部分的编程接口。让我们在使用时，完全可以依照Netty官方的教程来学习和使用DotNetty应用程序。DotNetty拥有一个强大的后台，所以我感觉这个C#版的Netty框架也会火起来的。
第一个应用
DotNetty带着Netty的诸多光环，还有一个强大的“爹”，于是说干就干，开始写了一个TCP连接的Listener程序，代码如下：
ProtocolV1ServiceFrameHandler frameHandler = new ProtocolV1ServiceFrameHandler();
frameHandler.ProtocolMsgReceivedChanged += FrameDecoder_ProtocolMsgReceivedChanged;
BYHXTcpIdleHandler tcpIdleHandler = new BYHXTcpIdleHandler(0, 0, 5);
tcpIdleHandler.LostConnectionChanged += TcpIdleHandler_LostConnectionChanged;
group = new MultithreadEventLoopGroup();
return new ServerBootstrap()
.Group(group)
.Channel<TcpServerSocketChannel>()
.Option(ChannelOption.TcpNodelay, true)
.Option(ChannelOption.SoKeepalive,true)
.Option(ChannelOption.SoBacklog,100)
.ChildHandler(new ActionChannelInitializer<ISocketChannel>(channel =>
{
IChannelPipeline pipeline = channel.Pipeline;
pipeline.AddLast("Idle", tcpIdleHandler);
pipeline.AddLast("framing-enc", new LengthFieldPrepender(2));
pipeline.AddLast("en", new ProtocolV1FrameEncoder());
pipeline.AddLast("framing-dec", new LengthFieldBasedFrameDecoder(int.MaxValue, 0, 2, 0, 2));
pipeline.AddLast("dn", new ProtocolV1FrameDecoder());
pipeline.AddLast("handler", frameHandler);
}));
上面的代码看起来没有任何问题，于是我就找了一个TCP客户端模拟器，可以连接没有问题，我又打开了一个TCP客户端，问题出现了，我通过cmd（netstat -an）命令行工具看到我第二次打开的连接是TIME_WAIT,之后打开的连接都是这个状态，我百思不得其解，于是我打印了netty的log，添加如下代码：
InternalLoggerFactory.DefaultFactory.AddProvider(new ConsoleLoggerProvider((s, level) => true, false));
通过Console窗口看到的log发现第二个之后的连接****ProtocolV1ServiceFrameHandler****通道处理器初始化失败了，我对比了事例发现在实例化通道处理器的又唯一的区别，如下：
pipeline.AddLast("handler", new ProtocolV1ServiceFrameHandler());
这，，，有区别吗？不明白。忽然，我记得我查看ChannelHandlerAdapter可用的重载方法是看到一个可重载的属性IsSharable，表示通道是否可以共享，于是我把这个字段设置为true。OK！！！可以了。
总结
虽然这次调试通过了，但是一个通道那两中声明方式的差异性，或者说Netty框架处理的差异性，有何区别，我目前不得而知！我一直坚信，不刨根问底的程序员不是好的程序员，我还坚信，源码面前了无秘密。因此，我接下来会对netty的通道机制做一次深入的源码级别的刨析......
