directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [RT] SEDA Package: Rework Proposal (long, sorry)
Date Wed, 24 Nov 2004 21:22:17 GMT
Berin Loritsch wrote:

> My initial reaction to what is currently the SEDA package is that in 
> order to
> do what I want would result in a hack.  I'm not opposed to doing that 
> for the
> short term, but I do want to look at a sustainable future.  While the 
> networking
> part isn't the bread and butter of Eve and Kerberos, it does play an 
> important
> part.  Things like firewalling (dynamic and static), load shedding 
> (for protocols
> that allow that sort of thing), and load balancing are all network 
> layer functions.

> After talking to Alex a bit, it seems that he, Trustin, and I are all 
> on the same
> page that SEDA needs a bit of rework.  The question of course is to do 
> it in
> a sane fashion.  That obviously means that we deal with a branch and 
> keep the
> one interface that everything else is defining and using.  Beyond that 
> is a question
> of what would make the best approach.
>
Let me also inject that I would like to see some statistics and user 
feedback too.  The good thing about doing this release with the current 
SEDA framework is that we get things out there for people to complain 
about.  That gives use feedback and requirements.  I would also like to 
bang requests against both servers to see where the performance 
bottlenecks are so we can design with these in mind.  I don't want to 
design the next best internet protocol server framework without these 
metrics.  It makes me feel like I'm spinning my wheels.  I think we all 
agree with this.

> The purpose of this email is to get some dialog going to come up with 
> the best
> approach overall.  I am stating my thoughts as a starting point, and 
> am not
> married to these thoughts.
>
> Alex put together what we have now with the only intention that it be 
> quick
> and dirty and be something that could get the project going.  The SEDA 
> project
> fills that need right now.
>
> I understand Trustin comes to the table with the Netty2 library, of 
> which I must
> admit ignorance.  He also has been doing most of the work getting SEDA to
> work the way it does now.
>
> Now, I come to the table with an existing, well tested library that is 
> used by
> several projects including Excalibur, some more stuff at D-Haven, and 
> several
> commercial projects.  That is the D-Haven Event library.
>
> What I would like to propose is that, as much as possible, we avoid 
> NIH syndrome
> (Not Invented Here) and use stuff that we know works.  I will be the 
> first to admit
> that the D-Haven Event library as it is now is not a drop in 
> replacement for SEDA.
> It provides the plumbing work which can be leveraged for the final 
> product.  If it
> makes sense to use Event and Netty2 together under one umbrelly then 
> we should
> pursue that.
>
> Nevertheless, here is my understanding of SEDA in a nutshell.  As the 
> current project
> does right now, each stage listens for events, processes them, and 
> then sends new or
> processed events on to the next stage.  Everything is decoupled 
> through Queues or
> Pipes.  Typically each stage will have at least two output pipes: the 
> loopback pipe and
> the output pipe.  The loopback pipe is used to push events we can't 
> deal with right now
> out of the way until we can.  The output pipe of course is used to 
> push events on to
> the next stage.  With this basic structure, we can really do wonders 
> pushing events through
> the system using enqueue predicates, multicast pipes, load balancing 
> pipes, etc.
>
> D-Haven Event handles the core part of moving things through a 
> pipeline quite well,
> and is pretty well tested.  It comes to the table with the following 
> features:
>
> * An event pipeline (pre-matched pairs of a set of sources and an 
> event handler)
> * A thread manager (using whatever policy you want for pushing events 
> through each pipeline)
> * A rate limiting enqueue predicate
> * A multicast pipe
> * Asynchronous command management (including periodically recurring 
> commands)
>
Say Berin do you have documentation on the event package at D-Haven that 
is at 50K feet with some drill down.  I'd love to look at it.  Likewise 
I'd like to look at documentation on Netty2 and the Geronimo Networking 
code.  I think we should take the best of all the worlds here.  Plus I 
have some serious ACE research to do as well.  I think Trustin has been 
doing the same till now.

> Now, all this is just the skeleton of what makes a SEDA system go.  
> The real power is
> in what the stages do and how the pipelines and stages are 
> configured.  That part is not
> done in the D-Haven Event library.  The core set of stages that I see 
> we need are as follows:
>
> 1. ConnectionManager (this includes firewalling by dropping 
> unallowable connections)
> 2. Reader (start reading bytes from the stream)
>   * Router (1 pipe per protocol)
> 3. Decoder (use the decoder from the protocol handler)
> 4. RequestHandler (use the request handler from the protocol handler)
> 5. Encoder (use the encoder from the protocol handler)
>
> 6. Writer (start writing bytes to the stream)
>
These are the exact same components in SEDA btw. 

> The reader will route the ByteBuffers to the proper protocol (based on 
> a port mapping
> or something like that) which will then do all its necessary steps for 
> dealing with its
> own type of information, and write the response ByteBuffers to the 
> output stream.
>
> Later on we can look at the pipelines to use load-balancing pipelines 
> for each protocol
> as necessary.  That will allow us the flexibility to merely forward 
> requests to other
> machines in a DMZ if we need it.
>
> I haven't looked at the details of the rest of the stuff in the SEDA 
> package to see how
> that would best be served in this architectural view, but I am 
> definitely open to suggestions.
>
I think the best way to procede is to start up the dialog as you have 
recommended and have done.  This is excellent.  Now I think we should 
all get familiar with SEDA, Netty2, Geronimo Networking, D-Haven Event 
and the ACE architecture and incorporate them into our converstations.  
Let's start a branch or several branches where we can play with these 
ideas and these constructs.  Meanwhile let's get this release out the 
door and see what's good and bad about SEDA. 

I really want the best of all the worlds and could care less what we 
have at the end of the day so long as some very basic fundamentals are met:

1). I don't want users having to know SEDA theory to write a protocol 
server that snaps in to the framework.  So details can be hidden and 
administrators deploying servers can be concerned with SEDA settings and 
dynamics.  SEDA or ACE is just a model and we should not get carried 
away with it.  We are in the business of writing protocol servers not 
extending Matt Welsh's discertation.
2). Make sure we have a simple, clean and intuitive ProtocolProvider 
interface with helper interfaces whatever they may be
3). Make sure the framework leverages encoder/decoder pairs that can 
chunk data and maintain state between chuncks - this way we actually 
utilize non-blocking facilities to the fullest extent
4). Make sure the framework is fast and optimized for rapidly 
implementing internet protocol servers and in this regard I would like 
design decisions to be driven by some statistics and concensus
5). Avoid generic framework-itis: we want a specific framework for 
writing internet protocol servers that behaves sort of like inetd in a 
single process.

Lastly although least important in the decision making process I would 
like the internals to be easy to maintain and grasp for those developing 
the framework and maintaining it.  However this is less important than 
the points above.

Alex



Mime
View raw message