Hello, > > For example if client connects, you may recv(,,,MSG_PEEK) 5 bytes > > from client socket and check if this bytes are valid SSL2/SSL3/TLS1 > > record header (SSL2 and SSL3/TLS1 record headers are different). > > If yes, then you can call SSL_accept() on client socket > > if not, you can read()/write() > > This is definitely not legal on Windows and can, at least theoretically, > cause deadlock on any platform. I would strongly urge against this approach. > What if your recv(,,,MSG_PEEK) only returns one byte? OK, will be enough.
> "Polling on a stream socket until a certain number of bytes or a "message" > arrives is bad code. A stream socket, such as TCP, does not preserve message > boundaries because it provides a data stream. As such, the largest message > size an application can ever depend upon is one-byte in length. Code that > uses peeking to wait until a complete "message" arrives might never succeed > on stream-based protocols in Winsock where the data straddles multiple > system buffer boundaries, due to design decisions. The peek operation will > report the number of bytes up until the first buffer boundary. The bytes > remaining in the other boundaries might never be reported, resulting in an > incorrect count of data for code algorithms that depend upon the peek values > to be accurate. Subsequent peek attempts will not reveal the "hidden" data, > which can still be received from the buffers." Did I said something like that ? Best regards, -- Marek Marcola <[EMAIL PROTECTED]> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
