Bodo Moeller wrote:
On Mon, Jun 26, 2006 at 12:35:57PM +0100, Darryl Miles wrote:
Yes. During the first call to SSL_write(), OpenSSL may take as many
bytes as fit into one TLS record, and encrypt this for transport.
Then SSL_write() may fail with WANT_WRITE or WANT_READ both before and
after this first record has been written, until finally all the data
has been broken up into records and all these records have been sent.
Checky extra question: Out of interest what are the overheads for TLS
headers and block padding for bulk application data, is there an optimal
SSL_write() size that would align all of these factors in the encoded
output:
* TLS header/protocol overhead
* Cipher blocks and chaining modes (picking the most commonly used)
* Blocking mode padding overhead
* Ethernet 1500 MTUs
I presume the minimum is 1 byte, to be send and flushed at the receiver.
But maximum block size I read somewhere maybe around 16Kb ?
So if we were looking in the 1500 to 6000 byte region for a nicely
aligned SSL_write() size, what are the magic numbers ?
Yes. The other party is always allowed to start renegotiation, so
your SSL_write() call might be during renegotiation; but OpenSSL won't
try to read data from the other party during SSL_write() unless it
already knows that a renegotiation is going on.
This is great information too. This clears up another thread I recently
started about an application which is doing bulk writes having switched
off doing any SSL_read() until the bulk write phase had finished.
So my application doesn't have a deadlock situation. Since it won't be
instigating any SSL_renegotiate() and I'm not reading any new data from
my peer to be able to receive a renegotiate request. So SSL_write()
will never return WANT_READ for me.
It is still unclear how this would work, here is the strictest pseudo
code case I can think up. This is where:
* the exact address for the 4096th byte to send it always at the same
address for every repeated SSL_write() call and
* I don't change or reduce the amount of data to be written during
subsequent SSL_write(), until all 4096 bytes of the first SSL_write()
have been committed into OpenSSL.
Exactly. You should not change the amount of data (n), and you should
not change the contents of these n bytes. You may change the address
of that buffer (provided that the contents remain the same) if you
set the flag that you asked about. However ...
This is the clearest explanation so far. I fully understand this.
When you say "change the buffer location" do you mean the exact offset
given to SSL_write() in 2nd argument ? Or do you mean for repeated
calls to SSL_write() the last byte (4096th byte from example) address
remains constant until OpenSSL gives indication that the last byte has
been committed ?
Here I am asking "which buffer when?" and "what location?" in relation
to previous failed SSL_write() ?
I don't quite understand these questions.
You have been able to answer this with clarity in another response above.
Basically the exact address location given at any SSL_write() does not
matter. So I can have per-thread buffers (per-thread stack space) and I
can thread hop my 'SSL *' context without worry.
The only thing that matters relates to data contents and length:
* that once data has been FIRST introduced with SSL_write(), even if
that returned -1, I'm not allowed to alter the contents or reduce the
length within that I've already presented before.
I presume I am allowed to increase the amount of data in a subsequent
SSL_write() call, or does that break TLS block length previously setup ?
So for my priority queue implementation over SSL; I consider the data
committed from application to OpenSSL after the first SSL_write() to
present that data.
Maybe I can work on with what you've said for a few days (to better my
understanding) and provide a patch to better document this requirement
in SSL_write() and SSL_set_mode() man pages for future users.
Thank you for your response the exact application requirements are much
clearer to me now.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
