> Try the PRF it helps the ACE community to understand the platform you
are
> using and for members to identify their particular areas of expertise
with
> your problem such that they might offer sound advice.

OK. Please see below.

> It might be useful to upgrade from 5.2.1 to the latest stable release
> because IIRC there were a number of improvements to blocking and
> non-blocking behaviour of the SSL library components, over the few
> versions that have followed 5.2.1.

I'll try that too. What is the latest "stable" release?

>> Everything works fine, except that after a client connects, in the
>> handle_put of the first task after JAWS_Pipeline_Accept_Task (that
is
>> the one that is supposed to read the client's request), an attempt to

>> read from the SSL stream as below:
>>
>> io->read(handler, data, data->size());
>>
>> will return with WSAEWOULDBLOCK. If I go with a debugger and pause a
>> little before stepping over the read, it works OK.
>
> ok, what triggered the call to handle_put ? And if it is a false alarm

> why can't you reschedule it with the Reactor (synchronous mode) and
pick
> it up again. [I am talking fairly blind here because I am not familiar
> with the handle_put() call or the semantics of the "io" objects read
method].

It is not a false alarm IMHO. When a client tries to connect, the accept
handler is correctly invoked. Except that ACE seems to not be designed
with a protocol in mind that needs some bootstrapping (handshaking)
before actual communication can begin.

So the "logical" SSL accept (handshaking) that comes after the socket's
accept takes some time and I figured this is why I get to the read
sooner than this handshaking is over.

But after studiying the ACE_SSL sources for some days now, it seems that
the ACE_SSL code (at least tries to) handles this handshaking so that
after the ACE_SSL_SOCK_Acceptor::accept returns, handshaking is already
over. Or maybe I didn't understand something correctly? ::ssl_accept can
ever return before SSL handshaking is over? Should I wait until
something is finished? But wait for what?

Please help.


Below is the problem explained again.
--------------------------------------------->>

ACE VERSION: 5.2.1

HOST MACHINE and OPERATING SYSTEM:
Windows XP Professional

COMPILER NAME AND VERSION (AND PATCHLEVEL):
Microsoft Visual C++ 6.0 SP5

CONTENTS OF $ACE_ROOT/ace/config.h:

#define ACE_HAS_STANDARD_CPP_LIBRARY 1
#define ACE_NO_INLINE
#include "ace/config-win32.h"

AREA/CLASS/EXAMPLE AFFECTED:
JAWS with SSL support

DOES THE PROBLEM AFFECT:
COMPILATION? No
LINKING? No
EXECUTION? Yes.


SYNOPSIS:
For clients that connect via HTTPS, reading the HTTP request fails.


DESCRIPTION:
Starting from JAWS2, I changed the webserver as described in <a
href='http://groups.yahoo.com/group/ace-users/message/23921'>this
article</a>. Basically, I am using an ACE_SSL_SOCK_Stream instead of a
ACE_SOCK_Stream, changed the acceptor to get such a stream parameter in
the accept method and changed all read and write operation from
ACE_SOCK_Stream to
ACE_SSL_SOCK_Stream.

Now the webserver accepts HTTPS connections. Everything works fine,
except that when the execution gets to the read call on the JAWS_IO* io
in method JAWS_HTTP_10_Read_Task::handle_put, the read fails with
WSAEWOULDBLOCK as if there is nothing to read from the socket (yet!).


REPEAT BY:
If all tracing messages are off, and the web server is run outside of
the debugger, then the issue is present. If tracing is on, or I go with
a debugger and pause before executing the read, then it works.


Best regards,
Levente
------------------------------------
Levente Farkas
http://www.essentialdetails.com/

Interscope
where details become essential