directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [seda] A preview on redesigned SEDA (or Netty?)
Date Thu, 09 Dec 2004 13:41:32 GMT
Trustin Lee wrote:

>>I'm used to the SEDA style event model, and I'm not really straying that
>>far from
>>it.  However, I am optimizing on certain event types in the sense that I
>>am not
>>introducing new events when the events that are generated from NIO will
>>I'm also streamlining things a bit in the sense of each stage does one
>>thing, and
>>does it well--which is supposed to be its strength.
>That's good.  But 'events' in original SEDA was just a message in a
>pipeline, and broadcasting events using EventRouters will not be good
>for your health.

I only have one router, which maps events that belong to one port to the 
pipeline for protocol handling.  It's not too different from what MINA 
for the mechanism.  In essence, you do have a way of routing traffic on 
port 6666 to
the proper protocol handler.

Of course, I can change the mechanism and add an attachment to the 
selector so that
the proper pipeline is attached to the selectionkey when it is ready.  
Hmmm.  That might
be a better way to implement the routing.  Nevertheless something of 
that sort needs to
be there--the mechanisms might differ.

>>The thread management for the SEDA environment I am creating is
>>It can be only one thread, or it can be a proportion of threads to the
>>number of
>>processors, or it can be something much more complex (with multiple thread
>>pools, etc.).  The library I am using already has a ThreadManager and a
>>ThreadPolicies written.
>In MINA, thread manager is optional.  It is just a part of
>architecture.  Of course thread manager is important, but it is just
>another implementation of SessionHandler or ProtocolSessionHandler
>which decorates the original SessionHAndler or ProtocolSessionHandler.
I see.

>>I was thinking that the ProtocolHandler wrapper doesn't really care how
>>are going under the scenes, but if they wanted they could have a simple
>>way of
>>adjusting it.
>>For example, the SEDAServer is pretty much hard-coded in the sense that
>>the pipelines are set up.  You can adjust things in this manner:
>>// Yes its a singleton, but for good reason
>>SEDAServer server = SEDAServer.getServer();
>>Firewall firewall = server.getFirewall();
>>firewall.deny(InetSocketAddress("", 6666);
>>server.addProtocol( 8080, new HTTPProtocolHandler() );
>>// (And things would just work)
>>server.removeProtocol( 8080 );
>>// (And it is now uninstalled )
>>Now, if the user wanted to adjust the threadpolicy, I could
>>enable something like this:
>>SEDAServer.getServer().installPolicy(new SingleThreadPolicy());
>>That would stop the old ThreadManager, and restart everything with
>>the new thread policy.  Of course I can add some protections around it
>>as well.
>What you're talking about is just a counterexample for very simplistic
>example of decoration.  We can create FirewallDecorator or
>ThreadManager which can do the same thing in runtime.  The only
>difference is that MINA doesn't try to integrate all of them to core
>package.  Those are just decorations and optional.  Users will be able
>to choose them, and some common features such as firewall and thread
>manager would be able to be provided as a default internal decorator
>by frontend package (not core).
:)  Of course, there needs to be a way to add deny/allow settings to the 
Firewall at
runtime.  So far I am keeping things simple--at least in my mind.  I 
think the core
difference here is that MINA relies on decorators while SEDA 
accomplishes something
similar using stages to transform events as necessary.

Two different concepts regarding network programming.  And it is 
perfectly fine to
explore them both.  In fact, in this case I think it will be very 
beneficial.  As Alex
said, having two different networking libraries might be something where 
the end user
can pick what they want to tune their server for the demands that they have.


"Programming today is a race between software engineers striving to build bigger and better
idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far,
the Universe is winning."
                - Rich Cook

View raw message