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.
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.
- 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.
Elie
At 09:20 AM 6/7/2004 -0700, David Schwartz wrote:
> I'm currently implementing a server using overlapped I/O completion ports
> (Async socket), and I am using 2 BIOs (network/internal) to take care of
> encrypted/decrypted data. In my server, I need to know when the packet
> begins and ends so that I can executed accordingly. Is there a
> way to find
> out the length of a packet (for example reading a header first and then
> read the rest of the packet) or am I way off?
> Thank you in advance for your help.
You should not care. If you find that you care, you are most likely doing
something wrong.
SSL operates over TCP. It provides a TCP-compatible interface for the
encrypted side and a nearly-TCP-compatible interface for the unencrypted
side. TCP has no notion of record boundaries and therefore SSL's input and
output sides don't either.
Look at the BIO-pair example code.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Elie Lalo
Senior Software Engineer
Desktop Technologies Group
1414 Mass Avenue
Boxborough, MA 01719
Cisco Systems, Inc.
Tel : (978)936-1160
Fax: (978)936-2212
Url : www.cisco.com
