Re: generic socket operations and SSL

Am Freitag, den 20.11.2009, 12:38 -0800 schrieb Jake Donham:
> On Fri, Nov 20, 2009 at 6:36 AM, Gerd Stolpmann <[email protected]> wrote:
> > For enabling SSL I would rather suggest to change nethttpd_kernel so it
> > uses the multiplex_controller class for I/O instead of sockets. This is
> > not that difficult, and would make it fully generic. Essentially,
> > multiplex_controller is a generic communication endpoint that can be
> > implemented for almost any kind of I/O mechanisms (sockets, SSL sockets,
> > smoke signs, ...).
> 
> I had wondered about this as well. Since Nethttpd_kernel is written in
> a clever way that allows it to be used in both nonblocking and
> blocking styles, I wasn't sure if it was feasible to use
> multiplex_controller, since that is written as an engine (with
> when_done callbacks).
> 
> It seems to me that once you depend on an asynchronous /
> callback-based interface, there is no way to recover a direct-style
> interface, short of running the event queue or using a separate
> thread.
> 
> Would it be possible to run the event queue only until a particular
> event (or one of a set of events) has occurred? 

Yes, by jumping out with an exception.

> (I think in the
> current interface there is only a top-level run that finishes the
> whole event system.) Then in Nethttpd_kernel.http_protocol#block,
> instead of calling Unix.select directly, one could run the queue until
> the input or output multiplex_controller is ready. It is a little bit
> hard to see how the interface should look; somehow
> multiplex_controller would need to expose its resources in order that
> client code could wait on more than one of them.
> 
> Alternatively one might abandon the direct-style option in
> Nethttpd_kernel, and have Nethttpd_reactor be merely a wrapper around
> Nethttpd_engine, that calls Unixqueue.run to handle a whole
> connection's worth of events.

Historically, Nethttpd_kernel avoided event queues because this was
quicker to develop (there was a time constraint - it was sponsored
work), but there is no striking technical reason. With event queues, the
Nethttpd_kernel interface would look like:

- At creation time, the http_protocol class would get an event queue
  as argument
- [cycle] would return a Uq_engines.engine that transitions to [`Done] 
  when data is ready to be processed, or there is a timeout (i.e. a
  "user event") (or alternatively, a callback is invoked).
- A user event would still be an incoming token, or the successful
  sending of some response, or a timeout - no change here. The
  management of the input/output queues would be the same

On top of this, one can easily define a synchronous version of [cycle],
to be used in Nethttpd_reactor: The cycle engine is started, and the
event queue is run. When the cycle engine is [`Done] the event queue is
simply interrupted by raising an exception that is caught by the caller
of [run]. (That's how to stop an event queue at any point.)

In Nethttpd_engine the first half of the class http_engine would get
superfluous - this is more or less already handled in Nethttpd_kernel
(maybe except input flow control).

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
[email protected]          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july