netty-server with RoutingPipeline

[Trustin Lee]

Hi Gaerfield,

On Tue, Mar 10, 2009 at 7:32 AM, gaerfield <gaerfield at web.de> wrote:
>
> Provides netty a standard-way to implement a router? I thought for smth like
> the following case:
>
> public class RouterPipelineFactory implements ChannelPipelineFactory {
>    public ChannelPipeline getPipeline() throws Exception {
>        ChannelPipeline pipeline = Channels.pipeline();
>        pipelineAddFirst("router", new Router());
>        // several ways a message could pass
>        pipeline.addChild("1", new Unzipper());
>        pipeline.addChild("2", new DefaultObjectDecoding());
>        pipeline.addChild("3", new RawData());
>    }
> }
>
> public class Router extends SimpleChannelHandler {
>    @Override
>    public void messageReceived(
>            ChannelHandlerContext ctx, MessageEvent e) {
>        // reading a few bytes
>        ChannelBuffer buf = (ChannelBuffer) e.getMessage();
>        if (buf.readableBytes() >= 4) {
>            int messageType = buf.readInt();
>            switch (messageType) {
>                case 1:
>                    e.getChannel.getChild("1").messageReceived(e);
>                    break;
>                case 2:
>                    e.getChannel.getChild("2").messageReceived(e);
>                    break;
>                case 3:
>                    e.getChannel.getChild("3").messageReceived(e);
>                    break;
>                default:
>                    drop();
>            }
>        }
>    }
> }
>
> The content-type of the Message (defined in some kind of header) then
> determines how message gets to its endpoint or passes several optional pipes
> on its way (maybe not all messages are zipped).

You can write 4 handlers and add them one by one into a pipeline.

1) the handler that picks up a zipped message and convert it from
ChannelBuffer to other POJO.
2) the handler that picks up a serialized message and convert it from
ChannelBuffer to other POJO.
3) the handler that picks up a raw data message and convert it from
ChannelBuffer to other POJO.
4) the handler that drops the received ChannelBuffers, but it
shouldn't drop non-ChannelBuffers.

The handler 1, 2, and 3 are supposed to:

  * forward the messageReceived() event whose message type is not a
ChannelBuffer, because it means the message has been picked up by
previous handler and converted to a POJO.
  * forward the messageReceived() event that the handler can't
recognize.  For example, handler 1 will not recognize a serialized
message or a raw data message.  They will be forwarded to next
handlers.  If all three handlers don't recognize the message type,
then it will be handed off to the 4th handler.

The handler 4 will drop unrecognized messages (ChannelBuffer) because
it should be something else than ChannelBuffer if it was decoded
successfully by any of the previous handlers (1, 2, and 3.)

Now, you can add as many handlers as you want to support different
message types in a pretty flexible manner.  Also, if a certain handler
should not process a certain message type, you can define some POJO
type and make sure the handler to hand off the event without
processing it:

    public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) {
        Object m = e.getMessage();
        if (!(m instanceof MessageTypeOfMyInterest)) {
            ctx.sendUpstream(e);
            return;
        }

        // TODO process / transform the message

        // ctx.sendUpstream(e);
        // .. or ..
        // Channels.fireMessageReceived(ctx, transformedMessage);
        // .. depending on if you transformed the message object or not.
    }

If you don't need this much flexibility, then you could simply write a
single monolithic decoder that can decode all three message types, but
my guess is that you need such flexibility to turn on and off certain
parts of a pipeline depending on the type of a received message.  If
you thought something simpler, let me know more detail and I will try
to come up with better solution.

> Anyway, netty is a really impressive and easy usable framework with
> amazingly good documentation, great thanks for that.

I'm happy to hear that.  Once you get a good confidence that Netty can
be reommended to anyone who wants to write a network application,
think about writing a testimonial. ;)

  * http://www.jboss.org/netty/testimonials.html

HTH,

— Trustin Lee, http://gleamynode.net/