For some reason, my email client didn't want to indent your message. So
I'll put your text on the left and mine indented. Sorry about that.
I think I need to explain my problem a little bit more. I am going to break
the problem into 2 parts.
Part 1: handshake
How do we know how many bytes does the I/O completion port need to read
without waiting forever (note that I can solve this problem by reading one
byte at a time from the I/O completion port but this is not feasible
solution)? Hence I would like to read the header first to get the length of
the packet and then read the whole packet before sending it to the (BIO -->
SSL_READ) for more processing.
Just post a reasonably-sized buffer, say 2Kb to 8Kb. Give whatever you get
to OpenSSL and ask it if the handshake is finished.
Part 2: My own protocol/messages
When we write a packet, the first two bytes of our packet indicates the
length of the entire packet. From that, we know how many additional bytes
to read to get a complete message. The problem that we face now is that
1) The initial 2 bytes may no longer be 2 bytes after encryption
2) Assuming that we could decrypt those to bytes and find out the length,
the length will not match the actual number of bytes sent on the network due
to the encryption (i.e. after the packet is encrypted it is larger than the
original message size). We are trying to understand how to read the packet
using WSARecv since we don't know the actual size of our packet because of
the encryption.
Pass it a reasonably-sized buffer, say 2Kb to 8Kb. Give whatever you get to
OpenSSL and ask it if it has any data for you. You are still missing the big
picture -- as far as the encrypted side of the data goes, your job is to be
*invisible* and make it look to OpenSSL like it's seeing a normal TCP
connection.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
