Re: SSL support

[Jan-Henrik Haukeland]

Christian Hopp <address@hidden> writes:

> seeding: took you code
> threads: also took your code and more

I haven't learned SSL properly yet, but I'm planning on finalize the
zervlet ssl code next week. One thing I see they use in the
aforementioned ssl book are BIO objects instead of calling SSL_methods
directely. BIO objects are an abstraction but I'm not sure what's
easiest/best to use, but I will know more next week. So hopefully I
can pull some more hints up from my hat. Not that you seem to need it,
but code feedback is always a good thing.

> > I'm doing it like this since I'm planing on using zervlet on Win32
> > as well
> 
> "Danger" is your middle name... or better "insanity"? (-:

I'm not proud of it but if zervlet should take off, which I really
hope for (it's what I plan to earn a living from), I think I will have
to include the win32 market segment.


> Btw... why is monit multithreadded?  I mean, it is obvious that
> monit IS multithreadded...  but why did you do it so.

The only reason for using threads in monit (now) is to easily
integrate the http server. 

I'm only using two threads. One for the monit daemon and one for the
http server. Because the http server's accept-call blocks, the http
server cannot run in the same process as the monit daemon.  Another
and more important reason is to make the http/cervlet operate on the
monit daemon's runtime values (i.e. to utilize shared memory). Forking
off a new http process is not a good solution since a fork creates a
_new_ memory segment for the child process. By using threads the monit
http server can operate directely on values in the monit daemon, for
instance to start and stop programs and displaying "live" process
information. It's no easy way around it except using threads for
including the monit http server in monit (and threads are a "elegant"
solution).

BTW, I strongly support your work with integrating ssl in monit (both
for the http server and for client request). It's probably a good idea
to provide patches during your development work so we can comment on
the design solutions before everything is checked into the CVS. Just
like with your work on the excellent process code. 

Maybe you should bring the discussion up on the general mailing list
in case others want to comment as well (only the 5 commiters subscribe
to this developer list). What do you think?

-- 
Jan-Henrik Haukeland