Thanks DR, actually I was missing the part that I can keep the status of the message received in the session itself. I got perplexed as how do I first read the header and then decipher what message to expect and read it without getting into the header loop again.
But I think I should have read the details in protocol-codec sample first before panicking. What made my life easier is the requirement that I can process one message (request-response) at a time so figuring out the status of the message received in one session should be easy (whether still receiving bits of header or bits of data). In my earlier project even though there was only one fixed length message, but I had to process multiple request-response, time them out and retry a configurable number of time - if I had to do that here things would have become very messy. Thanks a lot, Shubhankar -----Original Message----- From: David Rosenstrauch [mailto:[email protected]] Sent: Monday, June 22, 2009 10:53 AM To: [email protected] Subject: Re: Handling variable length request/response in MINA I do something similar, using a binary protocol where messages vary in length based on data-length values in the message. And yes, I use a custom subclass of CumulativeProtocolDecoder for this. The code's a bit ugly, but it works. Essentially your decoder needs to handle 3 possible cases: * full, syntactically correct message received * part of a syntactically correct message received, and * syntactically incorrect message received Not sure what more info you're looking for, so if you email back specific questions, I'll respond with further explanations and/or code. HTH, DR Chowdhury, Shubhankar [WHQKA] wrote: > Thanks Emanuel but actually I the message lengths vary in each > message - that's part of the message itself. If you see the message > format "14-2-Data_length" - so starting at 14th byte and I will have > an short value giving me the data length. > > Once I receive the whole message then only I can apply the byte > off-sets to extract the message body and header etc. but with > in.available() I would have to know the message length before hand > isn't it? Am I missing something? > > Thanks, Shubhankar 847-700-4452 -----Original Message----- From: > Emmanuel Lecharny [mailto:[email protected]] On Behalf Of Emmanuel > Lecharny Sent: Friday, June 19, 2009 5:46 PM To: > [email protected] Subject: Re: Handling variable length > request/response in MINA > > 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 fly). > > Hope it helps. >
