On Fri, Jan 16, 2004 at 12:41:52PM +1300, Sam Vilain wrote:
> On Thu, 15 Jan 2004 16:58, Rocco Caputo wrote;
>
> > Can you investigate this some more? I originally tried to use
> > Net::SSLeay's accept() and connect() in non-blocking mode, but that
> > broke the SSL session negotiation.
>
> From SSL_accept(3ssl):
[...]
> So, passing in an O_NONBLOCK *should* work, but I think I have found a
> better way... read on.
[...]
> In theory, you should just have to call the function that calls
> SSL_accept() again.
You were correct. Gabriel patched the existing code to do this, and it
works. I think your better way has merit, though.
> > All of the blocking issues would be taken care of it we can drive
> > that process with select().
>
> Yes - let POE's IO drivers work. I was interested by
> BIO_f_buffer(3ssl); this returns a BIO like above that doesn't have a
> real file descriptor underneath, which I think would let you do this.
[...]
> Hey, maybe it's even possible to enact this using Net::SSLeay in its
> current state...
>
> </me looks>
>
> Yes, I think that the section in the manual page called "BIO
> interface" will let you set up a SSL processor disconnected from a
> filesystem handle; something like this:
>
> $rbio = Net::SSLeay::BIO_new(BIO_s_mem());
> $wbio = Net::SSLeay::BIO_new(BIO_s_mem());
> Net::SSLeay::set_bio($ssl, $rbio, $wbio);
>
> # put blocks in
> Net::SSLeay::BIO_write($rbio, $buffer, length($buffer));
>
> # do appropriate SSL command for current state of filter
> Net::SSLeay::accept($ssl);
>
> # put blocks in
> Net::SSLeay::BIO_write($rbio, $buffer, length($buffer));
>
> That way, there is nothing tangible for SSLeay to block on. Does this
> give anyone out there enough material to write
> POE::Component::Filter::SSLeay ?
I think it's enough material, and an SSL filter or driver would solve a
major design issue ("Where in POE does SSL fit?"). The project needs a
champion, though. I don't do enough SSL work to do it justice.
--
Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
