Hi, Trustin, I really appreciate your wonderful explanation! Could you also shed some light on this case when you have time:
When decodable() is called there are 3.5 complete packets of MyPacket, my decode() implementation will take out each complete MyPacket and leave the remaining untouched to wait for more data. In my previous post I said I just took out exact one MyPacket and return OK - I didn't care how many MyPacket are inside current buffer as long as it contains at least one complete MyPacket. It seems to work for me because I found inside decodable() the buffer position was adjusted automatically by one MyPacket after I "get" one MyPacket out in decode(). I just want to know if this is the recommended way to achieve what I expected. Thanks again! Trustin Lee wrote: > > On 3/19/07, mat <[EMAIL PROTECTED]> wrote: >> 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. > > The buffer position is always reverted back after decodable() is > invoked, but decode() should revert the buffer position by itself. It > is because decodable() is for peeking incoming data to choose an > appropriate decoder, and decode() is for actual decoding. If you want > to wait until the whole message is read into the buffer in decode() > implementation, you'd better not to modify the buffer position until > then. > > Trustin > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 > > -- View this message in context: http://www.nabble.com/A-question-about-implementing-MessageDecoder-tf3422797.html#a9584258 Sent from the mina dev mailing list archive at Nabble.com.
