Inverse of the LengthFieldBasedFrameDecoder

[peter.jb.ball]

Thanks for the reply John, 

Let me start by saying that I think netty is an amazing framework and I am really enjoying using it!

All I am after is an Encoder which writes the length of the message and then the message itself.

Not sure if this is the best/easiest way to accomplish this but up until now I have added an encoder with the following code to accomplish this:

    @Override
    public void writeRequested(ChannelHandlerContext context, MessageEvent event) {
    	
    	ChannelBuffer buffer = (ChannelBuffer) event.getMessage();
    	
    	byte[] array = buffer.array();
    	int messageLength = array.length;
    	int totalLength = messageLength + 4;
		
    	buffer = buffer(totalLength);
	    
    	buffer.writeInt(messageLength);
    	buffer.writeBytes(array);
    	
    	logger.debug("writeRequested: Sending message with total size: " + totalLength + " bytes");
	    
    	Channels.write(context, event.getFuture(), buffer);
    }

Because I have used this in several projects, I thought it would be nice if the netty framework could provide an encoder to accomplish this, providing options to set lengthFieldOffset, lengthFieldLength, lengthAdjustment and initialBytesToStrip to accomodate a wider audience. 




On 03 Sep 2011, at 4:31 PM, John D. Mitchell [via Netty Forums and Mailing Lists] wrote:

> 
> On Sep 3, 2011, at 03:27 , peter.jb.ball wrote: 
> 
> > Is there an encoder that does the inverse of the 
> > LengthFieldBasedFrameDecoder? 
> > 
> > I know its not a complicated piece of code by I have found myself writing 
> > code to achieve this more than once and, as such, it would be nice if 
> > something existing as part of the framework, perhaps called the 
> > LengthFieldBasedFrameEncoder ;-) 
> 
> I'm confused... you want something to write the length of the message and then the message?  Or are you really asking about a more general message construction system or even a full-blown messaging system? 
> 
> A lot of the complexity of LengthFieldBasedFrameDecoder is for dealing with so many complicated, existing formats but that's no particular reason to try and recreate that complexity if you're writing new protocols. For these cases, I suggest at least checking out DJB's 'netstring' format and the public expansion of that spearheaded by Zed and his 'tnetstring' format: 
> http://tnetstrings.org/
> 
> Hope this helps, 
> John 
> 
> 
> _______________________________________________ 
> netty-users mailing list 
> [hidden email] 
> https://lists.jboss.org/mailman/listinfo/netty-users
> 
> 
> If you reply to this email, your message will be added to the discussion below:
> http://netty-forums-and-mailing-lists.685743.n2.nabble.com/Inverse-of-the-LengthFieldBasedFrameDecoder-tp6756391p6756710.html
> To unsubscribe from Inverse of the LengthFieldBasedFrameDecoder, click here.



--
View this message in context: http://netty-forums-and-mailing-lists.685743.n2.nabble.com/Inverse-of-the-LengthFieldBasedFrameDecoder-tp6756391p6756823.html
Sent from the Netty User Group mailing list archive at Nabble.com.