On Sun, Oct 9, 2016 at 10:55 PM, Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
>
>> On Oct 9, 2016, at 10:47 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:
>>
>>> However, it might sometimes return SSL_ERROR_WANT_READ, in which
>>> case, the SSL layer wants to read, even though the application
>>> wants to write. Your job is to do the read on the SSL layer's
>>> behalf, and then retry the write.
>>
>> For this particular sub-case, let's say SSL-layer wants to obtain "n"
>> bytes from the socket/wire.
>>
>> So, in this case, is it ok to do a blocking-read on the socket, unless
>> "n" bytes are received (of course, a socket "error" will be handled in
>> the blocking-call; it's just that any socket-timeouts will not be
>> considered).
>
> Yes, you can do a blocking read (provided you have already flushed all
> pending writes).
Thanks a ton Viktor for the reply.
(Yes, in the above case I mentioned, all pending writes would have
been flushed).
Also, I will be grateful if you could let me know if ANY of the
sub-flows in ANY of the flows below is wrong, remembering that "bio1"
is the SSL-BIO where the app-payload-bytes are written in, and "bio2"
is the IN-MEMORY-BIO where the app-payload-encrypted-bytes emerge.
app <==> bio1 <==> bio2 <==> socket
Also, for all my cases, Nagle's algorithm has been disabled on the
client as well as the server, so every write (at client/server)
constitutes a packet-transferred.
a)
Can
BIO_write(bio1, buf, n)
return a positive, non-zero return-value other than "n"?
In other words, is it possible that only partial-bytes are written?
b)
Let's say
BIO_write(bio1, buf, n)
was successful in writing "n" bytes to "bio1".
So, will ALL the app-payload-encrypted-bytes be available at "bio2"
immediately in a synchronous manner (so that they can be immediately
sent to the server over the wire) ?
Implicit in this workflow is my assumption that SSL too builds up a
packet for every BIO_write done over "bio1".
c)
Will the following sequence happen exactly as follows ::
i)
App wants to read some bytes, but in a probing manner (bytes
may/may-not have been sent by server).
ii)
Now, currently, "bio1", "bio2", "socket" are in clean-state.
Nothing is pending "in the real sense" to be written/read anywhere.
iii)
When app does
BIO_read(bio1)
SSL_ERROR_WANT_READ would be returned (after all, "bio1" cannot
provide any app-payload-bytes unless it
has received any app-payload-encrypted-bytes from server).
iv)
Doing
BIO_get_read_request(bio2)
would return 0.
v)
So, we try reading 1 byte from the socket (in a non-blocking
manner, obviously).
IFFFF successful, we write the 1 byte into "bio2" (and so, "bio1"
will get the smell of a new encrypted packet).
vi)
Thereafter, when app again does
BIO_read(bio1),
(assuming we do not hit any re-negotiation case in this cycle) this time,
BIO_get_read_request(bio2)
will return a non-zero value "n".
vii)
We read the "n" bytes over the wire, and write them to "bio2".
viii)
Finally, the "m" decrypted-packet-bytes will be available at "bio1",
from the encrypted-packet
of length "n+1" bytes.
Is my story of 8-points in case c) correct? :)
I am sorry for bothering you so much, but I can take comfort from the
fact that such idiotic questions will help noobs like me integrate
openssl faster, with better understanding of the internals, which will
obviously lead to slicker code.
Thanks again to everyone for the help so far ....
Thanks and Regards,
Ajay
>
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
Regards,
Ajay
