I'm not a user of mina (yet, at least), but my understanding is that that's exactly what the session attributes are for -- storage of arbitrary data by the protocol.
The protocol codec filter tutorial demonstrates exactly this: http://mina.apache.org/tutorial-on-protocolcodecfilter-for-mina-2x.html There are two different cases described: (1) when you know in advance how many bytes to wait for; and (2) when you don't know in advance. In the latter case, they store the partial data into the session as an attribute. Jim > -----Original Message----- > From: Erinc Arikan [mailto:[email protected]] > Sent: Friday, May 22, 2009 4:48 AM > To: [email protected] > Subject: Re: MINA newbie question(message gets chipped 5 or 6 bytes every > time) > > Hi Emmanuel; > > Thanks for the help, I think that I solved my problem about handling > fragmented messages. The only remaining problem for me is to store > incomplete messages(stream of bytes) to the session, so that next time > rest > of the message comes I can validate message integrity, and if it's > complete, I'll be able to process the message. I know you said simply do > nothing, don't read it from the buffer, but I have delimited messages with > variable message sizes and with no info about message length beforehand. > So > I need to read complete buffer every time to see my last byte is end of > the > message byte. Therefore I will need to store some bytes back into the > session when the last byte stream I receive includes an incomplete > message. > > My question is how can I accomplish storing bytes back to the session? I > checked session's methods there's a write method but I think that it > writes > data back to client and that's not what I need. There are some > setAttribute > methods but they don't look relevant to me too. > > Can I use IoBuffer's put method to put back what I already read from the > buffer? If so what's going to happen when next fragment arrives. Will it > simply overwrite current buffer or will it add the next fragment to what > Buffer contains? My intuition says that it will be added but if so there's > another thing that I wonder, do I have to reverse the order of bytes while > putting them back to IoBuffer. > > I wish that I can test and learn the answers by trial and error, but > regenarating this special case is little bit hard. > > Thanks so much in advance. > > Erinc > > On Fri, May 15, 2009 at 5:26 PM, Emmanuel Lecharny > <[email protected]>wrote: > > > David Rosenstrauch wrote: > > > >> Emmanuel Lecharny wrote: > >> > >>> Be aware that you not only can receive a fragment, but may be - > depending > >>> on your protocol - more than one message in the same PDU (ie you may > receive > >>> 200 bytes, 2 times 78 bytes plus some more bytes associated with > another > >>> message). You have to deal with that. > >>> > >>> If the protocol is a text based one, you may have a look to the > >>> documentation : > >>> > >>> http://mina.apache.org/handling-packet-fragementation.html > >>> > >>> The tutorial explain how to handle fragmented messages, using a class > >>> extending the CumulativeProtocolDecoder class. > >>> > >>> Hope it helps... > >>> > >>> > >> Sorry, getting a little confused about one aspect of this though: > >> > >> I was under the impression that if I'm using TextLineCodecFactory that > it > >> takes care of all the message fragmentation work for me, and that my > >> handler's messageReceived method is guaranteed to be passed one and > only one > >> text line per method call. And so consequently, you really only need > to > >> deal with fragmentation if you're not using TextLineCodecFactory. Have > I > >> got that correct? > >> > > Yeah, you're right, if the message is a text based one. But if it's a > > binary protocol, then you can't use the TextLineCodecFactory, obviously. > > > > > > > > -- > > -- > > cordialement, regards, > > Emmanuel Lécharny > > www.iktek.com > > directory.apache.org > > > > > >
