Emmanuel Lecharny wrote:
David Rosenstrauch wrote:
Emmanuel Lecharny wrote:
Again, in your case, using a DummySession is not a good idea.
Point taken. That said, it looks like it's not actually going to be
all that hard for my decoder to check for whether the transport allows
fragmentation or not, and to code for that accordingly. (Certainly
much easier than writing my own implementation of a dummy session.)
So I think I'm going to go with that.
If you are TCP based, your transport _will_ fragment the date. You have
to take care of that.
Right. And so I've updated my decoder in such a way that it will do the
correct behavior whether the session is fragmenting the data (i.e.,
return false and wait for more data) or not (i.e., throw an exception,
since the message was incomplete).
FYI, I rewrote the LDAP decoder in ADS, and I didn't used the
cumulativeStuff, for many reasons. First, because its a binary protocol
where the PDUs don't have explicit frontiers (ie, no fixed size or
delimiters, just a length somewhere after a tag). I defined a statefull
decoder, storing the intermediate decoded data in a container (a java
object representing the object being decoded) into the session (one
session stores one object). When I know that the object is decoded, I
call the handler. Works perfectly, and I don't have to rely on a
cumulativeStuff.
However, my use case was a bit specific. When dealing with fixed size
PDUs, or delimited PDU (like line based protocols), using the
cumulativeStuff is a better idea, as you don't mix two different things
into the codec.
Now, in your case, I think you are right : handle the fragmentation in
the codec. It's guaranteed to work.
Cumulative decoder seems to be working out OK for me, once I adjusted
the decoder to handle both cases (fragmented and non-fragmented data).
Thanks,
DR
