[swift-server-dev] Draft proposal for TLS Service APIs(pleasereview)

Gelareh Taban 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
tested it.

According to
https://mta.openssl.org/pipermail/openssl-dev/2015-March/000861.html there
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...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170331/0a39da0b/attachment.html>

More information about the swift-server-dev mailing list