On Tue, 25 Sep 2001, Jay 'Eraserhead' Felice wrote:
>
> Looking at the ssl manpage, if you use SSL_get_rfd() to retreive the read fd
> for that connection, select() should still work. I recall select()ing on an
> SSL fd successfully, although I can't remember where. The SSL library will
> even work with non-blocking sockets so the only new case is that
> it is possible for tn5250_display_waitevent()/tn5250_terminal_waitevent()
> to return a data event but there isn't enough data to decrypt, so the SSL API
> would return that there is no new data (but it would have to read all the
> data on the socket, so we wouldn't spin on select()).
Not entirely true, but pretty close. It's possible for the peer to
request a re-negotiation at any time. When this happens, data is sent
back & forth on the descriptor (which would show up wiht select()) but
it doesn't actually return any application-level data.
This also means that sometimes an SSL_read() call actually requires us
to check the _write_ fds in select() before it'll be ready to be called
again, as well as sometimes needing the _read_ fds. Fun, eh?
> I just did a quick
> once-through the code, and I can't see anywhere that would be a
> problem---the way the handle_receive() "method" works is to hork as much data
> as possible and see how many records it can make out of it. As long as the
> SSL implementation keeps to those semantics, I don't figure you'd need to hack
> it.
>
But I would... because of the write fds... though, it'd probably work
"most of the time," if I didn't... :)
_______________________________________________
This is the Linux 5250 Development Project (LINUX5250) mailing list
To post a message email: [EMAIL PROTECTED]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/linux5250
or email: [EMAIL PROTECTED]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/linux5250.
