On Mon, May 07, 2001 at 01:19:36PM -0400, [EMAIL PROTECTED] wrote:
> > Moved to openssl-users.
>
> I wish you hadn't done that, because I was not subscribed to openssl-users.
> I'm subscribed now, but I hope I haven't missed any messages related to this
> between Saturday and today.
openssl-dev was wrong list. I consider people interested in the development
of the OpenSSL library are also subscribed to the -users list.
I should have sent you a carbon copy. I tend to read all answers to questions
I am involved in. I don't remember any.
> > On Fri, May 04, 2001 at 06:53:19PM -0400, Harrington, Thomas wrote:
> > > But doing a 4kB write, followed by a ~30kB one, the second
> > attempt would
> > > consistently fail to write and get -1 back from SSL_write().
> >
> > [My answer with the recommendation to call SSL_get_error()]
>
> OK, I did forget to mention that I call BIO_sock_should_retry() to see if I
> should try and write again, and I do write again, and again, with the same
> buffer and with the same failure.
As you are talking about using SSL_write() you should use SSL_get_error().
> I realize that a write call on a nonblocking socket may not write the data.
> But as I said: I only get failures if I set nonblocking using ioctl(). If I
> set nonblocking via fcntl(), there's no problem at all. It's not the fact
> that SSL_write() doesn't write immediately that I'm puzzled about, it's the
> fact that using fcntl() has a different effect on SSL_write() than using
> ioctl() does, and I want to know why. That's my real question: What
> difference does this make with openssl, and why? My code seems to work OK
> right now, but since I'm relying on undocumented behavior I don't really
> trust my fix yet.
Unfortunately you still do not supply information about your operating
system, so that we may miss discussion of implementation dependant behaviour.
I have just read the ioctl(5) manual page on HP-UX:
It says:
FIOSNBIO
For those character device files which support this command,
if the integer whose address is arg is non-zero, non-blocking
I/O is enabled; that is, subsequent reads and writes to the
device file are handled in a non-blocking manner (see below).
If the integer whose address is arg is 0, non-blocking I/O is
disabled.
Please note that here explicitly device files are mentioned. Sockets
are no device files, I am therefore not sure what happens when applying
ioctl() to a socket.
...
To prohibit non-blocking I/O from interfering with the
O_NDELAY flag (see open(2) and fcntl(2)), the functionality of
O_NDELAY always supersedes the functionality of non-blocking
I/O. This means that if O_NDELAY is set, the driver performs
read requests in accordance with the definition of O_NDELAY.
When O_NDELAY is not set, the definition of non-blocking I/O
applies.
...
while the HP-UX version only uses processes. FIOSNBIO is the same as
4.2 BSD FIONBIO, except that it does not interfere with the AT&T
O_NDELAY open and fcntl flag.
It therefore seems that FIONBIO does interfere with fnctl() unlike
HP's FIOSNBIO...
Anyway, I found the part about the "character device" most interesting
and would recommend you to cross check, whether ioctl() would be the
appropriate way to handle the socket. I don't think so.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
