Thanks Jim; I figured it out after spending some time on it, You need to use setAttribute field of the session. On Fri, May 22, 2009 at 4:19 PM, Jim Newsham <[email protected]>wrote:
> > 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 > > > > > > > > > > > >
