Hi
I haven't ever used BIO.. One more thing, after calling SSL_read we
need to call SSL_pending also to make nothing is buffered.. In case
SSL_pending returns non-zero than we can iteractively call the
SSL_read again until it returns SSL_WANT_read or Write..
Whatvever it returns, based on that we need to place the socket in the
read/write and error list of the Select call...
I would suggest used some already written non-blocking client code
available on the net..
HTH
-Krishna
On 8/18/06, David Schwartz <[EMAIL PROTECTED]> wrote:
> David Schwartz schrieb:
> >> The only signals that I have is readyRead() (emit when I can read data
> >> form socked) and bytesWritten() (emit when data was written to the
> >> socked). I seen that OpenSSL will only have data for read when
> >> an Record
> >> was complete transmitted. How can I find out the size of an Record?
> >> Then I can try to call SSL_read only when all data of an record are
> >> received.
> >
> > You can't teach your application SSL, and it would be
> > madness to try.
> >
> > If you are doing blocking operations, then no problem,
> > SSL_read will block
> > until it can read at least one byte of application data, which should be
> > what you want.
> >
> > If you are doing non-blocking operations, then no problem,
> > SSL_read will
> > never block. So just try any time you get data.
> I have try this, but call SSL_read 400 times will not help.
There's a bit of a language barrier. So I'm not sure I follow you
completely. If SSL_read returns WANT_READ, wait for another indication that
there is data from the socket and then call SSL_read.
> So I have an new Idea to use the BIO system with an memory buffer.
> But I need an call back for BIO_write() so that I can send it so the
> network when openSSL has something to send.
If you want to do all the network I/O yourself, use bio pairs. It is
very
important to remember in this case that you have 4 logically independent
streams of data:
1) Encrypted data is received from the socket and handed to the SSL
engine
to decrypt and pass to the application.
2) Plaintext is received from the application and handed to the SSL
engine
to encypt and send.
3) Encrypted data from the SSL engine must be sent on the socket.
4) Plaintext from your application must be handed to the SSL engine to
encrypt and send.
It is important that you think of these streams as logically
independent.
Do not assume, for example, that because you just received some encrypted
data over the network, there must be some decrypted data to hand to the
application. Check if there is, for sure, but don't assume it.
Another weird thing, any change in readiness could make any direction
possible. For example, a previous send of plaintext to be encrypted may have
failed, some data is *received* from the socket, and now that send of
plaintext to the SSL engine *succeeds*.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
