netty

这样一个pipeline：

 ChannelPipeline} p = ...;
 p.addLast("1", new InboundHandlerA());
 p.addLast("2", new InboundHandlerB());
 p.addLast("3", new OutboundHandlerA());
 p.addLast("4", new OutboundHandlerB());
 p.addLast("5", new InboundOutboundHandlerX());

　　在上例中，inbound开头的handler意味着它是一个inbound handler。outbound开头的handler意味着它是一个outbound handler。上例的配置中当一个事件进入inbound时handler的顺序是1,2,3,4,5;当一个事件进入outbound时，handler的顺序是5,4,3,2,1.在这个最高准则下，ChannelPipeline跳过特定handler的处理来缩短stack的深度：

　　3,4没有实现ChannelInboundHandler，因而一个inbound事件的处理顺序是1,2,5.

　　1,2没有实现ChannelOutBoundhandler，因而一个outbound事件的处理顺序是5,4,3

　　若5同时实现了ChannelInboundHandler和channelOutBoundHandler，一个inbound和一个outbound事件的执行顺序分别是125和543.

///

netty的项目中使用protobuf，巧妙定义proto完成不同消息的编码和解码处理

在基于netty的项目中使用protobuf，需要处理不同的消息，因此需要不同的编码和解码方式（如下）

p.addLast("protobufDecoder", new ProtobufDecoder(Communication.TRequest.getDefaultInstance()));
p.addLast("protobufDecoder", new ProtobufDecoder(Communication.TResponse.getDefaultInstance()));

 但netty中每个管道仅能注册一个解码和编码的方式，经过研究，想到把这些不同的消息封装成一个消息组，在不同的处理逻辑中再get相应的消息即可，而管道注册那边只需要注册一个消息格式：

p.addLast("protobufDecoder", new ProtobufDecoder(Communication.ProtocolMessage.getDefaultInstance()));

proto文件：
//封装Request和Response消息，这样netty可以统一编码和解码
message ProtocolMessage
{
	optional TRequest tRequest=1;
	optional TResponse tResponse=2;
}