mina-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: Handling variable length request/response in MINA
Date Fri, 19 Jun 2009 22:46:04 GMT
Chowdhury, Shubhankar [WHQKA] wrote:
> o o the whole format got garbled - let me try in plain text
> ----------------------------------------------------------
> ----------------------------------------------------------
> This might be a very dumb post but please help.  
> I have already used MINA for a few projects mainly using the
> CumulativeProtocolDecoder and RequestResponseFilter for the client
> applications and using TextlineCodec for a few server instances. But my
> next attempt is a bit complex where the data that comes is a structured
> data of variable length basically of the following format-
> Offset-LengthInByte-FieldName
> ------------------------------
> 0-8-application_id
> 8-2-Version
> 10-2-Type
> 12-2-message_id_number
> 14-2-Data_length
> 16-4-Reserved
> 20-data_length-Data
> The application would be a server listening to a port (TCP) and also
> would return back some response based on the type field. So the client
> would initiate by sending a "login-request" - in response we have to
> send "accept" or "reject", then the data would be flowing, then log-out,
> keep-alive etc and all of them would follow the above structure.
> How do I handle this using MINA? Is there anyway I can use the
> CumulativeProtocolDecoder?
Actually, it will easy. As you know the length of your message, it's 
just a matter of storing what has already been received in the session, 
until you got all the message.

The decoder must be able to stop in the middle of an int, for instance, 
which is not that complicated, assuming that an int is a fixed size 
element. You just have to check that you have 4 bytes available in the 
buffer to decode the int, otherwise, you just store the buffer in the 
session, and wait for the next bytes to come.

Sounds complicated, but it's not.

The real issue is if you have very long messages : in this case, you may 
want to stream to a file the incoming data, to avoid a OOM.

When you have received everything, then you can push the resulting 
eleme,t to your handler (if of course you built a data structure on the 

Hope it helps.

cordialement, regards,
Emmanuel L├ęcharny

View raw message