Hi Scott!
I do not know if I was clear enough there. Maybe I misunderstood but for
me the trickiest cases has been the handling around the parsing.
Like where to keep state. It is not certain that you only has to parse
the message twice. It might happen that even the second time you try to
frame it the message is not complete.
If you have a read buffer of 8k and the massage is 44k how would it
happen?
The parsing we use in SIP has a buffer as input but also any incomplete
message T so the state is kept there then also the buffer is marked
where the last part that been read and in the message T.
When returned the buffer is compacted and more bytes are read. So now
for Http this works but If you build a client the body can be quite
large. In SIP you have an additional problem since the message headers
can grow quite big too.
So just to make it more clear for me the thought part is how the
iterative nature of the read/parse combination is done.
I would be more then happy to rewrite the SIP parser as long as I
understand how that would be done with this API.
As Jeanfrancois said we just tried not to shake too much in the
beginning. The SipParser takes a byte buffer but then works on byte[]
level.
That is the only problem to solve since it would have to be rewritten a
little bit but it should not be to hard.
The two Sailfin classes involved implementing this are
com.ericsson.ssa.container.MessageProcessorFilter and
com.ericsson.ssa.sip.SipParser.
I had the same idea that the MessageProcessorFilter would be more
generic and the SipParser SIP specific.
Have also wrote a MSRP parser but that one was not donated but we could
always rewrite the SIP one once more when the Grizzly integration is
done all the way.
BR Stoffe
-----Original Message-----
From: Scott.Oaks_at_Sun.COM [mailto:Scott.Oaks_at_Sun.COM]
Sent: den 29 november 2007 17:22
To: dev_at_grizzly.dev.java.net
Subject: RE: Re: Protocol Parser proposal
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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
For additional commands, e-mail: dev-help_at_grizzly.dev.java.net