directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject [seda] Another architecture proposal
Date Tue, 30 Nov 2004 11:09:03 GMT

I thought about xxx model discussions on SEDA.  IMHO, it is getting
somewhat academic and being the cause of the project schedule delay. 
So I suggest you another architecture.  Please look at the attached
activity diagram.

I separated SEDA into two layers; I/O layer and protocol layer.  I/O
layer does all low-level I/O.  It fills up channel read buffer and
flushes out channel write buffer.  All you have to do is implement
IOHandler interface that you can get from the channel read buffer and
can put into the channel write buffer. Protocol layer is just a
specific implementation of IOHandler which encodes and decodes byte
stream from/into event objects.  The use of protocol layer is
completely optional, so you can make a high-performance or low-latency
network applications just bypassing protocol layer. Protocol layer
provides a ProtocolHandler which is similar to IOHandler except that
it interacts with SEDA using event objects.

SEDA I/O and protocol layer will be the core of SEDA, and we can build
Inetd-like feature (i.e. InetDB or protocol registry) of course.

The advantage of this architecture is that it is really flexible. 
There is no restriction on the use of SEDA.  Users can use I/O layer
only, I/O and protocol layer, or I/O and protocol layer including
inetd feature.

This architecture does not have any event routers. It just propagates
events to the next layer.  This could resolve the problem where
requests are informed before ConnectEvent is and where requests are
informed after Disconnect is.  It is because protocol layer is the
only place to fire events to ProtocolHandlers so that protocol layer
can control its order much more easily.


BTW, it took really long time to draw this diagram.  Enterprise
Architect is good, but it needs more UI improvements.

what we call human nature is actually human habit

View raw message