Re: [LINUX5250] tn5250 and SSL

["Jay 'Eraserhead' Felice" <eraserhead@xxxxxxxxxxxxxx>]

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