The SSL protocol makes a pure select based programming model difficult unless you're aware of what is going on in the SSL layer. The primary problem is the SSL handshake. This is where the two parties decide on an encryption algorithm, swap certificates and generate a secret key. There is a decent amount of back and forth during this phase. Once the connection is established a small amount of read ahead is needed if a block cipher was chosen as the encryption algorithm. These blocks are usuablly pretty small (64 bytes I think) so this usually doesn't present a problem.
A server will typically, on accepting a new connection, want to read from it. If you're using blocking sockets you can, at this point, perform the SSL handshake in its entirety. Because of the back and forth a slow/broken client can cause a hang during this phase so you're left with finding a way to time it out. Using select on the socket during handshake is one way to do this (I don't know enough about IO::Socket::SSL to say whether this is possible here). The openSSL API for performing the handshake will, if the socket is non-blocking, return whether the handshake has completed, failed, is waiting for incoming data or is waiting to output data. Combine this with a smarter select loop and you you manage time outs quite nicely.
In reply to Re: IO::Socket::SSL buffering issue?
by 5p1d3r
in thread IO::Socket::SSL buffering issue?
by althepal
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |