I followed the Sumup Server example. In decodable, normally check the body len. you don't have to care about the position since in decodable get() method is to get the length of the body. The rest of bytebuffer is saved in the instance of the AbstractMessageDecoder. One session is one instance of the AbstractMessageDecoder if you follow the Sumup Server approach.
2007/3/19, Coding Horse <[EMAIL PROTECTED]>:
I'm trying to figure out the relationship between decodable() and decode(). By trying and testing I got to the following conclusion but not sure it's correct or not. Please confirm/correct me. Thx! Say my decodable() implementation guarantees that the current buffer contains at least 1 complete MyPacket(but could be more). Since a call of method decodable() guarantees there is at least one complete MyPacket inside buffer "in". I handle this very packet and simply return MessageDecoderResult.OK. in my decode(). I don't have to worry about the remaining stuff in current buffer "in" - mina is so great that it will continue to call decodable() automatically to handle the exact same current buffer "in". The recycle continues until nothing is left in this buffer "in". I guess only after that the buffer starts receiving new data from external world. Coding Horse wrote: > > Hi, > > In my decodable() and decode() methods I use relative get of ByteBuffer to > check data ready or not and return MessageDecoderResult.NEED_DATA when it > is not ready. > > My question: > Should I care about the buffer's position/limit etc. before returning > MessageDecoderResult.NEED_DATA? My "get" changed the buffer's position, > right? > > thx a lot! > -- View this message in context: http://www.nabble.com/A-question-about-implementing-MessageDecoder-tf3422797.html#a9540526 Sent from the mina dev mailing list archive at Nabble.com.
