On Thu, 2007-11-29 at 10:19, Kristoffer Gronowski wrote:
> Hi!
>
> The problem is that how do you know that the ByteBuffer bb contains an
> entire message.
> We have the SIP parser in Sailfin and for UDP this is the case but for
> TCP/TLS you could have:
> One fraction of T, one T or 1 1/2 T.
>
> And to know you have one T and where to stop you would have to frame the
> message and it's half of the parsing.
So I think you're saying that a message-based parser is bad, and that a
parser that understands the state of the buffer is good? If so, that's
the underlying point about my proposal.
But it is true that the simple implementation of what I've proposed will
lead to going through the buffer twice: once to find the boundary, and
once to understand the message. I used SIP as a test protocol for this,
and finding the boundary is quite fast, but a better parser would also
save some of that information for future use. So in fact, maybe what's
needed is both interfaces: the hasMessage/nextMessage so the parser can
let the grizzly framework know about when to read the buffer, and
something to get the message (already parsed) out of the buffer?
Sailfin doesn't presently use the ProtocolParser and
ParserProtocolFilter -- are there plans to move to that? I wasn't
actually sure from the sailfin source where the parsing is presently
done.
-Scott
>
> BR Stoffe
>
> -----Original Message-----
> From: Jeanfrancois.Arcand_at_Sun.COM [mailto:Jeanfrancois.Arcand_at_Sun.COM]
> Sent: den 29 november 2007 16:14
> To: dev_at_grizzly.dev.java.net
> Subject: Re: Protocol Parser proposal
>
>
>
> charlie hunt wrote:
> > We should probably solicit some input from Harsha or look at his
> > webrevs for the work he's done on integrating Grizzly with
> GlassFish-CORBA.
> > Perhaps Harsha can share with us a link to his webrevs?
> >
> > AFAIK, Harsha is the one who would be the most impacted by the change
> > to ProtocolParser. I don't know of anyone else who is using it. If
> > someone knows otherwise, please speak up.
>
> Harsh is probably the only one that used that API :-) Since his
> implementation is not final, I would think we should apply Scott
> proposal and then cut the 1.7.0 tomorrow.
>
> >
> > I may want to think about the "parse bytes and execute" versus "parse
> > bytes and dispatch to another thread" approaches. Prior to the
> > optimized read, we used to do the former. Btw, it's probably not
> > obvious that there is another queue involved in GlassFish-CORBA which
> > a Message passes through prior to getting to the encoding /decoding
> layer.
> >
> > charlie ...
> >
> > Scott Oaks wrote:
> >> I've been looking a lot at the protocol parser and related classes in
>
> >> the last few days and have a proposal for a different sort of
> interface.
> >>
> >> The present interface (com.sun.grizzly.ProtocolParser) is based on a
> >> parser that returns abitrary messages:
> >> public T parseBytes(ByteBuffer bb)
> >>
> >> But if the parser is called from the grizzly framework (e.g. from
> >> com.sun.grizzly.filter.ParserProtocolFilter), nothing really can be
> >> done with the returned message. The ProtocolParser has methods to set
>
> >> the buffer position and limit around the message, but if there are
> >> multiple message in the buffer, there's no good way to pass a single
> >> message along the filter chain or do any other developer interaction
> with them.
>
> Agree.
>
> >> Hence, the current implementation works only if the socketread has a
> >> single, complete message that can be passed to the next filter.
>
> My background with http is following me :-)
>
> >>
> >> What I propose is changing the ProtocolParser interface to this:
> >> public interface ProtocolParser {
> >> public boolean isExpectingMoreData(); // parser has a partial
> >> message
> >> but needs more data
> >> public boolean hasMoreBytesToParse(); // parser has data --
> >> maybe a full or partial message
> >> public boolean hasNextMessage(); // parser has a
> >> complete message and knows its boundaries
> >> public void getNextMessage(); // parser
> should
> >> set up the buffer to reflect next message
> >> public void setBuffer(ByteBuffer); // buffer on
> which
> >> parser should operate
> >> public void releaseBuffer(); // parser
> >> shoud setup buffer for next read
> >> }
> >>
> >> This would allow ParserProtocolFilter to be written so that in its
> >> execute() method, it calls getNextMessage, and the buffer can be
> >> passed along the filter chain for futher processing. Then its
> >> postExecute() method can see if there is more pending data, and if
> >> so, it can signal that the default processing loop should reinvoke
> >> (so the next message is parsed and passed down the filter in turn).
>
> +1
>
> >>
> >> I actually have that all working, but one potential downside to this
> >> is that multiple messages received in a single read call are
> >> processed by a single thread; CORBA presently can process each
> >> message on a different thread. In the code I was prototyping, I
> >> actually wanted the single-thread per socket read behavior, but I can
>
> >> see where both are useful. The CORBA-type behavior is more suited to
> >> the existing
> >> (message-based) interface; it still requires some way for the
> >> protocol filter to dispatch the message -- in which case, perhaps the
>
> >> ProtocolParser needs to have an associated filter list itself or
> >> something? Or maybe there needs to be a sync/async flag to control
> >> how the messages get dispatched? At any rate, that path would also
> >> require some changes to the interface and to the existing
> ParserProtocolFilter.
>
> Can you post the entire patch?
>
> >>
> >> So I'd instead propose we go with the changed interface (or that
> >> there be two interfaces, and someone address the message-based one
> >> implementation). [Or maybe there's a way to combine them that I'm
> >> just not seeing?]
>
> I think we should explore your complete patch and make sure the Corba
> team agree with the change. Since they are using 1.6.1, there build will
> not breaks until they switch to 1.7.0 :-)
>
> What other think?
>
> Thanks
>
> -- Jeanfrancois
>
> >>
> >> -Scott
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> >> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>