On Sat, Nov 28, 1998, Ralf S. Engelschall wrote:
> On Sun, Nov 29, 1998, Anthony Rumble wrote:
>
> >[...]
> > When will EAPI have writev support..
>
> I've now again searched for the details. When we want to create a SSL_writev()
> by trying to emulate writev() we have no chance. On most systems writev() is
> not a wrapper around write(), is actually a specially implemented syscall and
> it's done too OS specific. But we can simply try to adapt the existing
> SSL_write() to a SSL_writev(). I've looked into SSLeay and this is a lot more
> easier. So, I'll give it a try this afternoon. Don't understand why I didn't
> came to this idea first... :-(
Shit, forget my idea: I've now crawled through the SSLeay code in depth and as
it looks we have absoletely no chance to really implement a SSL_writev() which
is _not_ based on SSL_write(). The reason is mainly because between the
function entry point and the final network I/O there is _A LOT OF_
not-abstracted SSL record layer stuff (fragmentation, MAC addition, etc.) and
the whole code is bristled over different functions for SSLv3, then again for
SSLv2, etc.
But there is one possibility: We can increate the network I/O performance
(which is our goal why we wanted to use writev()) by slightly increasing the
CPU cycles and memory consumption (which us usually acceptable). According to
STEVENS' benchmark tables for writev() vs. write() when you have the memory
available for a temporary concatenation buffer, the additional CPU cylces for
concatenating the iovec's of writev() are worth the network performance gain.
Because except for the buffer concatenation and the memory overhead a write()
for the concatenated buffer _IS AS FAST AS_ writev().
So we could do the following: We write a SSL_writev() function which is a
wrapper for SSL_write(). But instead of calling SSL_write() for every iovec
entry (which would be silly and this way we're not better as currently with
NO_WRITEV) we can do the following: We have a pre-allocated memory buffer
available of around a few KB. We use this buffer to on-the-fly concatenate the
iovec entries into a single buffer and then call SSL_write() on this single
buffer. When the sum of iovec's doesn't fit into this pre-allocated buffer we
still have to use multiple SSL_write(), of course. But usually we should
succeed with a buffer of no more than 50KB.
What do you think?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
