multi 'layer' protocol

["이희승 (Trustin Lee)"]

Hello Ashish,

On 06/28/2010 08:40 PM, axhixh wrote:
> 
> Hello,
> 
> I am trying to implement existing Java code with old IO (blocking) using
> Netty.
> 
> The communication is compressed/uncompressed, encrypted/unencrypted using
> XML messages. 
> 
> Each message has a header with "compressed size/uncompressed/type". The
> sizes and type are not a fixed length fields. The size is sequence of ASCII
> number characters. I read it in till I find '/' and then convert it to a
> numeric value. Type is a 3 character string to indicate
> compressed/uncompressed and encrypted/unencrypted state of the stream.
> 
> In the old Java code I used multiple streams. The raw input stream was
> wrapped by decrypt stream (if encrypted) and then by decompress stream
> before receiving the XML output. The wrapping by different streams were done
> as necessary. 
> 
> The connection is persistent and more messages are sent on the same
> connection.
> 
> I am trying to implement this in Netty.
> 
> Based on what I have read I am trying to implement this with 4 handlers:
> 1. Frame. Reads the header, finds the length and reads the necessary bytes
> to create a frame.
> 2. Decrypt. Decrypts the frame if the frame has been encrypted.
> 3. Uncompress. If the frame has been compressed this uncompresses it.
> 4. Final message handler. Handles the XML message.
> 
> To avoid huge memory usage and be efficient, I would like to keep passing
> ChannelBuffer instead of using different objects between handlers. In this
> case, how does the different handlers (which all get the same object) know
> if they should process it or pass it on? Is there a way, I can set a channel
> specific value that I can pass between the handlers? Is this the recommended
> way?
> 
> I would reset this variable so that I am ready to handle the next message.
> Is there something like a 'ChannelContext' or similar? What is the way to
> pass values from one handler to another?

I'd rather define a new message type that wraps a ChannelBuffer so that
an additional state information is accompanied.  I don't think it will
be inefficient.  ChannelBuffer will take much more memory relatively.

On 06/28/2010 08:52 PM, axhixh wrote:
> Just found the class ChannelLocal. Is this the recommended way to
> pass around values shared by all handlers?
>
> The first handler has access to compressed, uncompressed and type. So
> the first handler could set these values and various handlers read
> these and decide what to do.

ChannelLocal is not suitable in this case.  Later you might delegate
some processing to other threads and then you will need additional
synchronization, which will make the code very complicated.

HTH,
Trustin

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 293 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100629/aa8702f3/attachment-0001.bin