Michael Wojcik <[EMAIL PROTECTED]> writes:
> > Just use buffered I/O.
>
> I'd be interested to hear if this works (ie. if in practice it generally
> manages to coalesce adjacent sends). I imagine it would, but I haven't
> tested it yet. Of course, this will involve a buffer copy.
I have tested it. It works fine.
> Not when the connection is performing no transformations (encryption,
> hashing, etc.) on the data. That's not inconceivable; many SSL-enabled
> applications communicate with both SSL-enabled and non-SSL-enabled peers, or
> only use protected connections for sensitive data. HTTP user agents, for
> example. Since OpenSSL provides a nice socket I/O abstraction, it makes
> sense for such applications to use OpenSSL BIOs regardless of whether
> they're actually using OpenSSL's data transformations.
Obviously, scatter/gather I/O is of value when you're not doing SSL.
That's why writev() and readv() exist in the first place. However,
this isn't an argument for SSL_writev() to exist, it's an argument
for BIO_writev() to exist. Then the socket BIO can map BIO_writev()
to writev() and the SSL BIO can map BIO_writev() to a series of
calls to SSL_writev()--or to buffered writes. Doing anything more
complicated would require demonstrating that buffer copies are
a substantial cost when doing SSL, which, as I've said, they're
not likely to be.
> Eric's point - that buffer copies are unlikely to be a significant portion
> of running time - only holds if the buffers aren't very large.
Not so. The cost of transmitting an SSL record is linear in the
size of the record. Since the size of the copied buffer also
scales with a size of the record, the fraction of runtime consumed
by the buffer copy is roughly constant.
> (It's not
> just total application running time that's important here; users don't like
> noticeable delays during any portion of processing, even if they're
> negligible over the process's runtime.)
Since buffers are always broken up into records of <16K, this really
isn't relevant. Processing latency is generally quite small.
> Of course, all this is entirely theoretical - I haven't actually profiled
> any of this under OpenSSL.
I generally prefer to inform my theorizing with some data:
Algorithm Speed (k/s)
memmove 652234
RC4 45212
SHA 31646
MD5 63855
As you can see, memmove()--which is generally slower than memcpy()--
is far faster than any of the actual crypto algorithms. Thus, even
if we always copied every record into a temp buffer before
encrypting it would be likely to have only the most minimal impact
on performance.
To go back to what I said at the beginning, the only situation in
which marshalling to a tmp bufffer is likely to cause significant
performance effects is when memory is EXTREMELY tight and so
a lot of allocation and deallocation is required.
-Ekr
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
