On another host, you could receive several ByteBuffer messages that
not necessarily correspond to the ByteBuffer that was sent, so you
could receive split messages like the first example

However, TextLineCodecFactory is already prepared for that, so if you
are using it, then on you handler you will always receive the complete
String message that was sent; the protocol filter will wait until the
entire string is received (until the \n marker) and only then pass the
message to the handler, so you don't have to worry.

If you do want to implement your own protocol, then you will have to
keep the splitting in consideration, but it's not the case in here

hope it helps

Andres

On Mon, Oct 13, 2008 at 10:34 AM, Stephane Rainville
<[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I started playing with Mina a got a small client / server application working 
> using the default TextLineCodecFactory using strings.
> "messagetype,param1,param2,param3,etc,\n"
>
> So far everythings works nice but after Reading the "Tutorial on 
> ProtocolCodecFilter (for Mina 2.x) " I'm left to wonder that it works because 
> I'm testing on localhost and the buffer is always complete.
>
> AM I correct in my understanding that in real life I could receive messages 
> in IoHandlerAdapter.messageReceived that look like this
>
> "messagetype,param1,p"
>
> Or even worst a split of 2 messages
>
> "param5,\n,messagetype,param1,param2"
>
> I would like confirmation of my 2 assupmtions please. (But would be happier 
> that I'm wrong)
>
> If so then I hope Maarten Bosteels complete his delimiter tutorial.
>
> Thanks

Reply via email to