SessionFilter顺序

 

在实现Cindy 3.0a3 SSLFilter的过程中，发现一个有意思的问题：不同类型的SessionFilter对于过滤事件的顺序有着不同的要求。

 

假设有这么一个场景，通过SSL连接接收和发送数据，并统计所有的网络流量。

 

对于接收而言，SessionFilter的顺序应该是：

Received Packet --> StatisticFilter  --> SSLFilter --> Application Packet

这样统计到的是真实的接收流量，应用拿到的也是解码后的数据。

 

对于发送而言，SessionFilter的顺序则应该是：

Application Packet --> SSLFilter --> StatisticFilter --> Send Packet

可以看到，对于发送和接收而言，这两个Filter的顺序是相反的。如果这个场景再复杂一些，数据发送前需要先进行压缩，接收到数据后再解压缩，那么从发送到接收的整个流程是（红色是发送，蓝色是接收）：

Application --> ZipFilter --> SSLFilter --> StatisticFilter --> Network --> StatisticFilter --> SSLFilter --> ZipFilter --> Application

可以看到在这些场景中，Filter在处理发送和接收事件上顺序是相反的。而在以前Cindy的设计里面，对于所有事件的分发都是按照相同的顺序，这可能造成困惑。

 

目前我的想法是，针对 应用层 的Filter， 将所有的send/sent事件分发按照Filter添加的顺序反向分发，其他的事件则按照添加顺序分发 。 但这种做法缺乏灵活性，因为这暗示了所有Filter需要的就是这种顺序（虽然目前除了系统级的Filter外，我还没想到什么样的Filter处理发送 和接收事件的顺序需要保持一致）。另一种做法可以把所有事件都拆分开，指定每个事件的处理顺序，但这种做法言应该会过于繁琐。

 

目前Cindy内系统级Filter对发送和接收事件分发的顺序需要保持一致。如果在上面这个流程图中加入系统级Filter，那么整个顺序是这样的（红色代表系统级Filter）

发送：Application --> ExecutorFilter --> ZipFilter --> SSLFilter --> StatisticFilter --> PacketDecoderFilter --> SessionHandlerFilter

 

接收：Network --> ExecutorFilter --> StatisticFilter --> SSLFilter --> ZipFilter --> PacketDecoderFilter --> SessionHandlerFilter

虽然这种全部反向分发接收事件的做法还有待商榷，但可以肯定的是，该做法比原来所有顺序一致的做法要好，因为反向分发至少覆盖了大部分的应用类型。

 

如果你来设计，你会怎么做呢？