David Schwartz wrote:
My first reaction was that this is a bug in the library, but I
didn't feel
very strong about it and would have accepted that this is just a bug in
s_client. I like your argument about the library not having the right to
make 2 blocking calls unless retry is set and now I'm back to thinking
that this should be fixed in the library.
I'm pretty confident that the fix (if it is feasible) is not going to
break any correct application code.
And I'm pretty confident that it is going to make app. engineer's life
easier.
Why is the number of blocking calls significant? How are two blocking
calls
different from one?
Its to do with the application programming paradigm for doing IO.
You start with a working program using raw syscalls. We can use
poll/select to drive the need to service IO requirements.
Now you want to add OpenSSL to is.
The claim here is that now you get an IO programming paradigm which
doesn't conform to the model your program is already using for blocking
IO. Which works on the platform its on when there appears to be no need
for that to be the case.
Instead now the concept of blocking IO goes under the heading "voodoo
and black magic". When I've not heard one reason why that has to be the
case.
If anyone thinks that 'select' or 'poll' guarantees that a future
operation
will not block, even if it's a single operation, that's just plain not true.
The only way you can guarantee that even one operation will not block is if
you set the socket non-blocking.
Really.
I dont think the IEEE and POSIX specifications are publicly available to
quote you an extract. However the Linux man page talks in those
specific terms of a descriptor becoming writingable means that a write
operation will not block (I think its widely accepted that they are
referring to only the next single invocation of write() will not block).
I believe a version of Linux (around 2.0 or 2.2 passed POSIX testing)
and I don't believe the behaviour of the current kernel has changed
since that time. So while I don't have the exact specs you want to hand
I'm confident the implementation of these syscalls within linux is correct.
But obviouly the Linux implementation isn't "the standard".
I can't quite see the point of not setting auto-retry. You make blocking
socket operations when you want to block until they can be completed. What
possible use would half-blocking be? To try as hard as possible to find the
corner cases where you think you won't block but then accidentally do?
But thats the point. Its not about "half-blocking" its about the
interation between poll/select events and the OpenSSL library so that
the library more easily slots into application programs which use
conform to that platforms blocking socket IO model. I am expecting the
library to just extend that.
I have not heard any reason why it needs to be the way it is. Maybe if
OpenSSL implemented an event notification scheme which would slot into
the poll/select model there would not be a problem. But thats not the
case and I've heard no technical reason why a half-blocking mode not
possible.
Please show me the standard that says that the return value from
'select'
or 'poll' guarantees that a future operation will not block. It cannot be
done. Operations on blocking sockets can *always* block. That's why they're
called 'blocking sockets'.
Maybe you can show me your standards that cover the select() system call
you have ? What standards are you working to ? If there are no
standards maybe you can demonstrate an implementation of the select/poll
system call that doesn't work that way. Then explain how normal
blocking IO on sockets works on that platform (including interaction
with signal handling, transport layer errors, buffers becoming full,
etc..). I'm pretty sure form that all I can describe to you how OpenSSL
would work for that platform in that situation.
I'm thinking along the lines of transparency of that platforms blocking
socket IO model, and less black magic voodoo (which only bite developers
in the ass).
In my limited wisdom this simply boils down to allowing just one
blocking lower layer IO to be performed per higher level call in.
Anything else needs to be restartable, since OpenSSL support
non-blocking mode its already got the infrastructure in place to be
restartable.
In a way its cheeky of you to be asking for standards to backup the
syscall as if it has any bearing or weight in this thread. The thread
comes from the more practical approach of how systems are and how
implementations are of existing application software. The request is
just for the operating systems blocking design paradigm to be maintained
through to the high level SSL API calls (SSL_read()/SSL_write()) etc..
It would be true to say that if the platform doesn't support the
poll/select blocking socket paradigm we are expecting then that program
(you are adding OpenSSL) won't be written in that way. This makes what
the exact specification of poll/select is in relation to blocking IO
irrelevant, we just want transparency of whatever that model is at
syscall level on that platform brought out to the SSL API calls.
So there is no point in getting tangled up on the topic of select/poll
syscall specification.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
