Undestanding the pipeline

["Trustin Lee (이희승)"]

On 2009/12/15 8:34 pm, Iain McGinniss wrote:
> Responses inline below...
> 
> On Mon, Dec 7, 2009 at 10:13 PM, justkevin <filter.netty at wx3.com> wrote:
> 
>>
>> Hi all,
>>
>> I have a couple questions about the pipeline and processing incoming
>> messages (I'm new to Netty, so these questions may be a bit naive):
>>
>> 1.) What's the difference between overriding handleUpstream and
>> messageReceived? I see that one gets a ChannelEvent and the other gets a
>> MessageEvent, but I'm not sure how to decide which one to override. Also,
>> if
>> I override both in a handler, why is it that messageReceived isn't
>> triggered?
>>
> 
> handleUpstream is the generic upstream event handling method - here, you
> will have to do instanceof checks to determine what type of upstream event
> it is, if that is relevant to your processing. messageReceived only deals
> with data reception, and is a convenience method provided for overriding by
> the SimpleChannelUpstreamHandler class. If you take a look at the source of
> SimpleChannelUpstreamHandler<http://www.jboss.org/file-access/default/members/netty/freezone/xref/3.1/org/jboss/netty/channel/SimpleChannelUpstreamHandler.html#76>
> you'll
> see it is doing the instanceof checks in handleUpstream on your behalf.
> 
> 
>>
>> 2.) Let's say I expect the first thing to come from the client to be an
>> authentication string. If they authenticate, I want to treat the rest of
>> their data as length field based frames. I think this is roughly how to
>> handle it using the pipeline model:
>>
>> Pipeline factory adds an AuthenticationHandler.
>> The AuthenticationHandler looks for a string.
>> If the string is "good", add a LengthFieldBasedFrameDecoder and a
>> MessageHandler, remove the AuthenicationHandler. Pass the MessageHandler a
>> user object maybe?
>> Otherwise, close the connection (maybe send some kind of rejection
>> message).
>>
>> Is that more or less correct? Thanks in advance for any help!
>>
> 
> This seems like a sensible approach., but I'll let the others comment on
> this. In some ways, I wish it were easier to encapsulate this kind of
> pipeline state transition, so that adding / removing handlers at runtime was
> so explicit.

It depends on if the client sends the message right after the
authentication string without waiting for the acknowledge from the
server.  If there's such req-res pattern for authentication, it will work.

Otherwise, implementing the AuthenticationHandler will get a little bit
trickier than expected because the client can send the authentication
string and its following data together:

  "SESAME" 0x00000008

where "SESAME" is the passphrase.  You have to hand the next four bytes
(0x00000008) somehow to the newly added LengthFieldBasedFrameDecoder.
Fortunately, you can do that as described here:

  https://jira.jboss.org/jira/browse/NETTY-187

The example in the issue page above discusses about replacing a decoder
with another decoder, but it can be applied to replacing an ordinary
handler with a decoder, too.

  return new Object[] { passphrase, remainder };

could be replaced with multiple event calls:

  Channels.messageReceived(ctx, passphrase);
  Channels.messageReceived(ctx, remainder);

Or perhaps you don't even need to trigger the first event if you don't
need the passphrase anywhere in the pipeline

HTH
Trustin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20091216/881a3fc3/attachment-0001.bin