>> I have not tested it very much but it shows my problem though..
>> If a non-ssl client connected and did not do anything everything just
>> hung.. Net::SSLeay::accept only returns if it got bad data or a
>> disconnect.. Mmmm single threaded apps..
[ ... ]
>
> Please let us know when you've found a good TIMEOUT value. I'll use
> 5000 (five seconds) for now.
I do not think there is a general good timeout value for everyone. I
saw one case where a single threaded webserver started with a timeout
of 0.1 seconds and then increased it for every failed handshake caused
by timeout until it reached maximum 5 seconds.
> Does anyone know if Net::SSLeay::accept() starts by sending or receiving
> data?
Receiving according to the code and tcpdump:
server:
$ openssl s_server -nocert -nbio -msg -accept 7777
client:
$ nc localhost 7777
I need to type in 11 bytes to make server-side break connection and a
tcpdump says only client is sending data.
OpenSSL-code (lib/s23_srvr.c) says:
int ssl23_get_client_hello(SSL *s)
{
char buf_space[11]; /* Request this many bytes in initial read.
* We can detect SSL 3.0/TLS 1.0 Client Hellos
* ('type == 3') correctly only when the following
* is in a single record, which is not guaranteed by
* the protocol specification:
* Byte Content
* 0 type \
* 1/2 version > record header
* 3/4 length /
* 5 msg_type \
* 6-8 length > Client Hello message
* 9/10 client_version /
*/
[...]
n=ssl23_read_bytes(s, sizeof buf_space);
[...]
> If it's the latter, we can defer calling it until select() says there's
> data ready. TIEHANDLE can do everything up to the accept() call, then
> we can wait for the client to send something before accepting the
> connection.
Not sure but maybe we could select and peek until we got 11 bytes and
then pass it on to SSL_accept?
--
/Gabriel
