On Fri, Oct 7, 2016 at 9:19 AM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote: > On Fri, Oct 07, 2016 at 08:51:24AM +0530, Ajay Garg wrote: > >> However, I am a bit unsure about certain implementations. >> In particular (let's talk only about the client-side), I wonder how do >> the following methods work internally :: >> >> >> * SSL_connect (implicitly involving underlying-socket-reads and >> underlying-socket-writes) > > Correct. > >> * SSL_write (involving underlying-socket-writes) > > This can also involve socket reads, e.g. when the peer requests > renegotiation. Hence, on non-blocking sockets this can fail with > SSL_ERROR_WANT_READ. The application should then retry the write > (generally with the identitical data) when the socket becomes > *readable*. > >> * SSL_read (involving underlying-socket-reads) > > This can also involve socket writes, e.g. when the peer requests > renegotiation. Hence, on non-blocking sockets this can fail with > SSL_ERROR_WANT_WRITE. The application should then retry the read > when the socket becomes *writable*. > >> We have a framework which we have ported to a variety of devices, >> involving GPRS-connectivity, and devices without operating-systems. >> I know that there is "no one universal socket-write" and "no one >> universal socket-read" implementations. > > No idea what "root-level" means. Perhaps you mean something > analogous to a system-call? If so OpenSSL can either be handed > the socket to use, or plugged into some other way of moving data > via the BIO pair interface. > > https://www.openssl.org/docs/manmaster/crypto/BIO_s_bio.html Ahhhh.... let me have a look.. I think this will fit in :) > > -- > Viktor. > --. > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Regards, Ajay
