× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




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




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.