× 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, Sep 25, 2001 at 04:31:54PM -0500, Scott Klement wrote:
>
>
> 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?

Ehr, hmmm... thinkthinkthink.   I see what you mean.  From Linux experience
(I think BSD, too), the write buffers are large enough that you'll never ever
run into that problem.  Bah, that would be bad code (and horribly difficult
bug to find if it ever did show up).  Yeah, gotta hack terminal and stream
to handle a separate write fd *sigh*.

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

Hehe.  You're right.  And the times it didn't work probably wouldn't show up
when you were stepping with a debugger 'cause the send buffer on the socket
would have time to clear <g>.  Yup, better hack the select().

>

-Jay 'Eraserhead' Felice


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.