Re: [LINUX5250] tn5250 and SSL

[Scott Klement <klemscot@xxxxxxxxxxxx>]

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... :)