monit-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Some SSL stuff.


From: Jan-Henrik Haukeland
Subject: RE: Some SSL stuff.
Date: Thu, 14 Nov 2002 18:35:18 +0100

> On Tue, 5 Nov 2002, Christian Hopp wrote:
>
> > > BTW, you will need some kind of timeout or better, a non-blocking BIO
> > > used by SSL_accept() in embed_accepted_ssl_socket() to avoid a block
> > > and server hangup since the current check for timeout first happen in
> > > process.c, i.e. after SSL_accept().
> > The underlying socket are now embedded in a BIO.  That part works.
>
> And it still works!

Yahoo!

> > Now I also want to feather bed the ssl connection into a BIO, too.
>
> That would need a complete rewrite of the SSL engine and the
> surrounding socket engine. They would have conceptional differences.
> And that's a lot.

Yeah, I can imagine. Don't do it, you have put a lot of work into it and
besides, it works. I plan to use BIO all the way in my zervlet implementation
of SSL and can kick back some code if you really want to go for the BIO
abstraction. Unfortunately, I haven't yet started on the SSL implementation for
zervlets. I have had to focus on getting the engine ready with HTTP and
implementing the Servlet spec.

> Isn't it possible to surround the accept stage in the same kind of
> timeout frame like it is used in validate.c or would they collide?

If you're thinking about using alarm() it would probably collide, because alarm
is process wide and the alarm signal could be emitted from within two different
threads you could start the wrong alarm handler or suspend the monit process in
a state it shouldn't be suspended. In fact previous versions (<=3.0) of the
processor.c used alarm and I observed collision on more than one occasion. Not
often, but it did happen.

> Anyways, it seems to me we have make the underlying socket
> non-blocking in order to make the ssl connection non-blocking.  That
> means we need to do a
>   fcntl(s, F_SETFL, O_NONBLOCK)
> with our network socket.

It should be non-blocking before you call SSL_accept() and blocking afterwards.
Have you tried something as simple as:

 set_noblock(socket);
 SSL_accept(socket);
 set_block(socket);

This is the most important call to not have blocking, other stuff like
read/write in the SSL lib are probably using select() to avoid blocking (I
would guess).

Cheers!

Jan-Henrik

Ps. Regarding the 3.1 release, it's up to you and Rory, since the major new
things are the ssl stuff and the depend stuff (except Martin's mode patch
that's already in). Not to put any pressure on you guys, of course ;-)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]