How does Netty's built in channel handlers handle/discard/ignore non relevant events/msgs and/or propagate them to another handler

[L_DisplayName]

I am implementing a custom FTP protocol using netty. However, to get started I will have the server just send the length of the file, followed by the file contents. To do this I am following the FileServer.java and the FileServerHandler.java example that comes with netty. However, I have a few questions in regards to how netty handles events intended to be handle by just one handler when there are many handlers in the channel pipeline. For example, consider FileServer.java and the FileServerHandler.java

 FileServer.java
 p.addLast(
    new StringEncoder(CharsetUtil.UTF_8),
    new LineBasedFrameDecoder(8192),
    new StringDecoder(CharsetUtil.UTF_8),
    new ChunkedWriteHandler(),
    new FileServerHandler());

In the example all server outbound events will propagate in the following order through the channel pipeline

1. FileServerHandler
2. ChunkedWriteHandler
3. StringEncoder

However, the server sends a string to the client requesting the name of the file to send. My questions are:

1. How does ChunkedWriterHandler handle the String since ChunkedWriterHandler is expecting a chunkedInput specifically a ChunkedFile?

2. The NETTY API is not clear on this, is the String ignored by the ChunkedWriterHandler and sent to the String encoder? If so, how is it discarded? I looked at the ChunkedWriterHandler code and I did notice a discard method, but I am unsure if this applies to this scenario:

   discard method inside ChunkedWriterHandler Object message = currentWrite.msg; if (message instanceof ChunkedInput) { ChunkedInput in = (ChunkedInput) message; try { //Do something; } else{ Closed Channel Exception }

3. In addition, once the chunkedWriterHandler starts processing and sending chunkedInput through the channel pipeline, how does the StringEncoder handle chunkedInput? Does it ignore it (if so, how?) and just forwards it to the next handler, however in this case there are no further handlers so does it just writes the data to the socket or add it to a queue if flush was not called after write?

4. How does any Encoder write data to the socket? in many of the netty examples: Telnet (StringEncoder), factorial (NumberEncoder), etc., the encoder just writes the String or int to a ByteBuf, BUT WHERE IN THE ENCODER CODE IS THE ByteBuf actually written and flushed to the socket/wire?

[Victor Noël]

Hi,

I'm not netty expert, but from what I understand events (at least inbound ones, I'm not so used to manipulating outbound ones, but I guess the behaviour is mirrored) are not propagated except if you explicitly re-trigger them (with context.fireEventType(ev)) in the Handler method for the event.

[Norman Maurer]

That is correct. That said the `Adapter` classes usually do this for you.

-- 
You received this message because you are subscribed to the Google Groups "Netty discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netty+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netty/715a1b70-a8d6-49b3-ad63-f701fd90d43e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[L_DisplayName]

Thank you for your responses, I appreciate them. However, can you clear up a couple of more items I'm still confused about

For the FileServer Example:

The FileServerHandler Sends a String Msg to the client requesting the client to send a file name to retrieve.

The msg flow through the channel pipeline is as follows:

1. FileServerHandler 

2. StringEncoder

However, the outbound channel pipeine msg flow as specified in the FileServer is:

1. FileServerHandler

2. chunkedWriteHandler

3. StringEncoder

Question 1: How & why does the String msg generated from the FileServerHandler skip over the chunkedWriteHandler to the StringEncoder? What causes the ChunkedWriteHandler to be skipped over? Is this because ChunkedWriteHandler is expecting a ChunkInput and so the handler rejects any msg that is not of type ChunkedInput and passes it on to the next outbound channelHandler which will be the StringEncoder which is expecting a String. if so does the ChunkedWriteHandler automatically ignores the String msg and uses the (context.fireEventType(ev) ) method to push the msg to the StringEncoder

When the fileServerHandler sends the contents of the file, it uses chunkWriteHandler if zero-copy is not allowed on the native machine and therefore the msg flow through the channel pipeline is as follows:

1. FileServerHandler

2. chunkedWriteHandler

Question 2: How does the data stream generated by chunkedWriteHandler bypass the StringEncoder? What causes the StringEncoder to be skipped over? I know the StringEncoder is expecting a String to decode to write out to the socket, but how does data stream generated by chunkedWriteHandler bypass the StringEncoder