Port Unification, in Grizzly, is represented by PUFilter which is a Grizzly 2.2.10 FilterChain Filter. This filter plays role of a fork in the FilterChain.
Each "unified" protocol, should be represented by a object pair:
ProtocolFinder, which is responsible for parsing incoming data and figuring out if the data belongs to the specific protocol;
FilterChain, represents specific protocol FilterChain.
So the final FilterChain will look like:
For better usability, Grizzly Port Unification introduces the PUProtocol abstraction, which holds ProtocolFinder + FilterChain pair.
The picture above is not complete, one piece is missing. We can imagine how new data comes from network, comes into main FilterChain, it redirects it to the corresponding protocol FilterChain.
But what about opposite direction? Imagine HttpServerFilter wants to send data back to the client, so it constructs HttpPacket and send it by the custom protocol FilterChain. HttpFilter intercepts the HttpPacket, decodes it into a Buffer and... there is no Filter in the custom protocol FilterChain to pass the Buffer to, so it never comes to TransportFilter and never gets sent! In order to fix that, we need to add utility back channel Filter as the first Filter in the protocol FilterChain, which will be reponsible for redirecting custom protocol FilterChain processing back to the main FilterChain. So finally complete picture will look like:
The PUFilter logic could be described using follwoing flowchart diagram:
