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

[Gelareh Taban]

> > [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
coordinate?
>
> Are we still talking about
>
>   func tlsWritev(vectors: AnyCollection<iovec>)
>
> ?? What has been proposed is simply supporting `writev` semantics (man
writev).


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
separately.
http://stackoverflow.com/questions/38198638/openssl-ssl-write-from-multiple-buffers-ssl-writev


(I would assume the latter technique would also work in LibreSSL and other
forks)

** 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.

g.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170331/0a39da0b/attachment.html>