Hi Emit,
>
> Thanks to Alex's earlier suggestions I got a sort of working grizzly2
> based implementation of my protocol... then I tried mina 2 and was
> shocked that all the plumbing was in place. I cooked up a decoder
> based on their standard CumulativeProtocolDecoder and had it
> working in a few minutes...
I find your this very interresting...
You got me curious.
if its not to much work for you,
would it be possible to share your mina 2 and grizzly 2 implementation code.
Pseudo would also be ok
Many Greetings John
>
> For example, there's a method in mina's IoBuffer called
> prefixedDataAvailable(x,y), which returns true if there are n
> bytes waiting to be read where n is represented by the next x bytes,
> usually 2 or 4...
>
> I don't know offhand if such a thing exists in grizzly
> (I apologize if it exists), and I admit, it's trivial to implement,
> but small things like that which come up frequently when decoding
> a binary protocol could be either refined or better documented.
>
> In the meantime I have two branches in my cvs, one for mina2 and
> one for grizzly2 so I'm just gonna try both back and forth. They
> are actually eerily similar.
>
> -Emit
>
> On Tue, Dec 16, 2008 at 06:38:30PM -0500, Survivant 00 wrote:
> > that's really nice.
> >
> > is it possible to do the same thing with a variable length message ?
> >
> > you could have a annotation for the start (probably not needed) or the
> end
> > of query.
> >
> > a message is completed when you found the eoq. and if you reach the max
> > buffer size(annotation) you throw a Exception ? (maxBuffersize..)
> >
> > that will save me 200 lines of code for the parser in 1.x .
> >
> >
> >
> > 2008/12/16 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>
> >
> > >
> > >> Hi Emit,
> > >
> > > coming back to your question, if it's not late...
> > >
> > > What is the best "grizzly 2.0" way to cut up the incoming stream
> > >> into these logical packets of data, hopefully without editting
> > >> the grizzly internal classes? I guess I can just aggregate
> > >> these getMessage Buffers myself after the handleReads but in that
> > >> case I don't see a reason to use this framework with all the
> > >> overhead involved.
> > >>
> > > Yesterday we've added new feature in Grizzly 2.0, which may help you
> with
> > > message parsing.
> > > Please take a look here [1]
> > >
> > > Thanks.
> > >
> > > WBR,
> > > Alexey.
> > >
> > > [1]
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger