[swift-server-dev] Draft proposal for TLS Service APIs(pleasereview)
gtaban at us.ibm.com
Fri Mar 31 09:55:40 CDT 2017
> > [g] Agreed about general efficiency, but with TLS, you would need a
different context for each of these streams.
> I can’t follow you. Which different streams? What do you want to
> Are we still talking about
> func tlsWritev(vectors: AnyCollection<iovec>)
> ?? What has been proposed is simply supporting `writev` semantics (man
I'll reword what my understanding is and let me know if I am incorrect. I
obviously haven't worked with vectored IO before so this is new for me.
I understand the benefit of iov and its single-copy properties when we call
readv or writev (efficiency + atomicity).
But this assumes we are using those functions in our implementation of TLS.
** In OpenSSL, there seems to be some support for it though I have not
is a patch that went in OpenSSL that supports iovec.
Also possibly we can do this via BIO with BIO_f_buffer(). It seems there is
one additional copy but it's still more efficient than treating each buffer
(I would assume the latter technique would also work in LibreSSL and other
** In SecureTransport, AFAIK there is no support for iov though our friends
at Apple may give us a definitive answer.
If iov is not supported in the underlying TLS library, then we go back to
treating each buffer in iov as a separate buffer and calling the SSL_write
on each buffer individually.
Furthermore, if not all underyling TLS libraries support vectored IO, then
having that as input to onReceive/onSend doesn't make sense.
Perhaps we can define new procedures in TLSService protocol for vectored IO
that return NotImplemented if underlying library doesn't support them, but
we need a basic one that handles one buffer at a time and is supported by
all security libraries.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-server-dev