directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <>
Subject Re: [seda] A preview on redesigned SEDA (or Netty?)
Date Wed, 08 Dec 2004 22:12:46 GMT
Alex Karasulu wrote:
> Richard Wallace wrote:
>> Hey guys,
>> I'd like to chime in if I might.  A network admin friend and I have 
>> decided to write a mail server in Java in our spare time, just for the 
>> fun of it.  I'm eager to play with using SEDA to handle the flow of 
>> operations, and was hoping I could use the SEDA library in this 
>> project as the basis for that.
> Coolio!
>> I'm a little confused on what you guys are discussing right now, tho. 
>> Most of what you seem to be talking about sounds like a pipeline with 
>> a fixed number of stages in it.  
> Right.
>> The reason I say this is because of the ProtocolHandler class.  It 
>> seems to me that you would also want to break up the ProtocolHandler 
>> into different stages.
> Yeah we could do that but the way this would be done would be very 
> specific to the nature of the protocol server.  Some servers I'm sure 
> would be very conducive to it.  We could write a really generalized 
> framework for that but one exists in commons called commons pipeline for 
> managing logical stages.   However by sticking to handling the network 
> plumbing aspects and creating a demarcation at the point of the 
> ProtocolProvider allows the SEDA framework to keep its focus wrt 
> networking aspects of the server.  This makes for a better framework.  
> The more general a framework gets the less useful it usually becomes IMHO.
>> For instance, in Matt Welsh's http server, Haboob, he had several 
>> stages dealing with cache and file IO and dynamic page generation.  I 
>> plan on looking to do something similar in the mail server my friend 
>> and I are getting ready to write.
> That's cool let use know where you're doing this.

ATM we're just going to self host our code.  Once we get a little bit 
more going and have decided that it's something we want to continue 
we'll probably start a SF project.  After that, we'd like to try and get 
into apache, if there is interest.

>> I'm curious how this type of ProtocolHandler would be constructed in 
>> Mina and Berin's SEDA implementation (I can't wait to see more code 
>> there).  
> With the present SEDA implementation you can use the stages to build 
> your own pipeline within the ProtoPro easily and that's up to u.  With 
> the common plumbing of several inet servers having an input, decode, 
> process, encode and output stage we took the liberty of hard coding this 
> outter pipeline.   Nest into it below the ProtoPro as you like.
>> Would you need to build a sort of sub-pipeline within the protocol 
>> handler to accomplish this?
> Just as I was describing above.  You can do this with the SEDA platform 
> I have been using in the trunk.  I would imagine we could do the same if 
> not better with the SEDA implementation Berin is working on.
>> I think it is very important that it is easy for someone to be able to 
>> plug in a new ProtocolHandler and be able to take advantage of the 
>> concurrency and scalability that the non-blocking IO and SEDA provide, 
>> but it should also be fairly straightforward to build new pipelines.
> Yep that's my primary concern with any API and the heart of the 
> framework.  Basically you have the common plumbing in place 
> (input,decode,process,encode,output).  Using the same stage component 
> for the stages in this prefab pipeline you should be able to build your 
> own pipelines inside the ProtoPro.

Alright, that's kind of what I was thinking.  Because servers also 
typically need to access some kind of backing store at some point.  For 
some things, like a DNS server, this could easily be done in a one step, 
but for something like a web server or email server this could be a 
multi-step process, or need to be asynchronous itself, such as when 
doing file IO.  I would think that even an LDAP server could benefit 
from more than one stage in the protocol handling because you've got to 
parse the incoming request and turn it into something that you can 
easily pass to your backend.  Then I would think that whatever backend 
your using, you would want that to be an asynchronous request 
(especially in the case where your backend is another ldap server or 
something else that could have a high latency).

I see your point that you want to make it as simple as possible and I'm 
all for that.  I've looked at the DefaultFrontend and 
DefaultFrontendFactory in the seda trunk and it does seem like it is be 
easy to build new and varied pipelines with it.  I just wanted to ask 
because while looking through Mina I got the feeling that it is mostly 
just concerned with abstracting the details of asynchronous network IO 
away from the developer and not necessarily processing requests in a 
pipeline.  To me that the core of what SEDA is all about, not just 
asynchronous IO, but asynchronous event processing.  Whether those 
events are network operations, operations to perform on an image or some 
other form of user input.


>> Everything I've seen so far looks great.  I'm eager to try this stuff 
>> out in my own project.
> Both Trustin and Berin have some great ideas in addition to the SEDA 
> framework we have in the trunk.
> Cheers,
> Alex

View raw message