At 02:43 PM 4/27/01 +0200, Bodo wrote:
>On Fri, Apr 20, 2001 at 11:29:51AM -0400, Tom Biggs wrote:
>
> > I'm implementing code to do OpenSSL handshake/read/write
> > for some radically different hardware. These will completely
> > replace the standard OpenSSL handshake state machine
> > and most of the API functions at the SSL_METHOD level.
> >
> > I am used to I/O return codes where
> > ( > 0 ) means success
> > ( == 0 ) means I/O block but otherwise no problem
> > ( < 0 ) means error
> >
> > So far, I've implemented all my routines to work that way.
>
>Usually 0 means EOF. 'I/O block' is a return value of -1 with errno
>set to EAGAIN or EWOULDBLOCK, these days (O_NONBLOCK semantics).
>You'd see 0 in these situations only if you use O_NDELAY, but you
>should not do this: The O_NDELAY semantics make it impossible to tell
>the difference between EOF (connection closed) and a EWOULDBLOCK
>situation (connection open, but no data available) for read requests.
>
>(While often both O_NDELAY and O_NONBLOCK are available, luckily only
>the latter is standardized.)
OK, thanks, Bodo. I guess I've been wrapped up in embedded
programming for too long - it must have overridden my Unix knowledge.
In most of the embedded systems I've been working on, a zero
return from an I/O function means "nothing right now, come
back later".
Now please excuse me, while I go pull my foot out of my mouth. :-)
>When SSL_read() etc. return 0 this means that EOF was encountered.
>To find out if this is an error, you have to call SSL_get_error();
>it might be a legitimate closure.
>
>When SSL_read() etc. return -1, this is not necessarily an error;
>it might be an EWOULDBLOCK situation. Again you'll have to
>call SSL_get_error() to check.
>
>You don't have to look at SSL_{connect,accept,read,peek,write} return
>values in your program; just pass them over to SSL_get_error().
>For positive return values, SSL_get_error() will always return
>SSL_ERROR_NONE; but for 0 or -1, there's usually not much the
>application can find out by itself.
I'm actually inside OpenSSL, looking out. As I mentioned in my
introductory paragraph, I am writing a set of modules which
will pretty much replace the s3_*.c (and s23_*.c) modules.
This is in support of a radical new NIC. The basic underlying
OpenSSL I/O model will not work on this hardware [1], so I am
writing *all new* functions to do all SSL_read/write/accept/connect
operations [2].
I just want to make sure that I understand how the existing functions
return status, so that mine work compatibly. Thank you for your
assistance.
It turns out that I don't have to change as many OpenSSL modules
as I thought at first. I'm splicing my functions in at the SSL_METHOD
level, so the high-level calls drop in transparently. Outside of that,
so far I've only had to modify SSL_get_error and a bit of the alert code
(the only two areas I've come across thus far that weren't built into the
METHOD pointer scheme).
[1] well, it *could*, but all the neat optimizations would have be
turned off, and that would destroy the performance advantage.
[2] which is why I posted to this list and not -users.
Tom Biggs
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
