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

[Gelareh Taban]

Hi Helge,
sorry for the delayed response.

> I suppose what you have been saying about EAGAIN etc may work out.
> It would be really nice to actually try the API with an NIO consumer, did
you do this already?
> Just to make sure and test out that we aren’t missing something.

What is an NIO consumer? I see that Java has New I/O (
https://en.wikipedia.org/wiki/New_I/O_(Java)) - how would this work in the
context of Swift?

(that should also answer your question ;-)

If you are talking about non-blocking by any chance, we have an
implementation of this in BlueSSLService (
https://github.com/IBM-Swift/BlueSSLService) which interfaces with a socket
management layer (BlueSocket - https://github.com/IBM-Swift/BlueSocket).

Ideally we want to abstract away the transport layer and that's actually
the next protocol that I referred to in the original proposal that we want
to tackle and you have started alluding to in the next paragraphs.



> Wrt the GCD channel stuff. Well, your design has that separate service
object which is ‘used' by some ‘Socket’ class.
> With GCD in mind I would design the TLS support as a new custom channel
which is just wrapping a GCD channel.
> It would provide the same API like GCD plus the necessary extras. Kinda
like OpenSSL BIOs, just with async.

> But this would tie the I/O to a GCD API style (not necessarily to GCD,
you could factor out the channel API
> as a ’stream' protocol). Quite likely this is still not desirable for
everyone.

Really interesting. Dispatch IO has:

https://developer.apple.com/reference/dispatch/dispatchio
class func read(fromFileDescriptor: Int32, maxLength: Int, runningHandlerOn
queue: DispatchQueue, handler: @escaping (DispatchData, Int32) -> Void)
class func write(toFileDescriptor: Int32, data: DispatchData,
runningHandlerOn queue: DispatchQueue, handler: @escaping (DispatchData?,
Int32) -> Void)

Are you talking about these APIs? How would it work with stream?



> I haven’t seen a proposal on how (byte) streams are going to work for
Server Side Swift
> (i.e. how the API of the HTTP Request/Response body streams would look
like). That kinda ties into this.


> Summary: The service object as you proposed should be fine as a support
wrapper used by higher level
> I/O objects. I guess it is the right way to go to support various I/O
styles. Just wrap OpenSSL and
> the macOS thing. Do not add anything else.
> But *if* we would get a proper (byte) streaming abstraction, I would
prefer if a TLS stream would
> live on top of this (be a stream itself and wrap the stream representing
the connection).


I agree about the stream abstraction. In order for us to completely
abstract away the transport layer, streams are ideal and preferred.

What is tricky here is that Streams in (mac) Foundation has TLS support via
property keys.

https://developer.apple.com/reference/foundation/stream

Most probably they are using the SecureTransport APIs and passing the
stream by reference while implementing the TLS read/write operations from
the stream via callsbacks.

So the question would be, do we only provide APIs that stream can invoke on
Linux (which probably take in file descriptors with a transport type) or do
we provide an extended set of APIs that Stream can use, while we also have
Stream based transport abstraction? Should stream have multiple TLS
supports?


cheers,
gelareh




From:	Helge Heß via swift-server-dev <swift-server-dev at swift.org>
To:	swift-server-dev <swift-server-dev at swift.org>
Date:	03/23/2017 11:53 AM
Subject:	Re: [swift-server-dev] Draft proposal for TLS Service APIs
            (pleasereview)
Sent by:	swift-server-dev-bounces at swift.org



Hi Gelareh,

I suppose what you have been saying about EAGAIN etc may work out. It would
be really nice to actually try the API with an NIO consumer, did you do
this already? Just to make sure and test out that we aren’t missing
something.


Wrt the GCD channel stuff. Well, your design has that separate service
object which is ‘used' by some ‘Socket’ class. With GCD in mind I would
design the TLS support as a new custom channel which is just wrapping a GCD
channel. It would provide the same API like GCD plus the necessary extras.
Kinda like OpenSSL BIOs, just with async.

But this would tie the I/O to a GCD API style (not necessarily to GCD, you
could factor out the channel API as a ’stream' protocol). Quite likely this
is still not desirable for everyone.


I haven’t seen a proposal on how (byte) streams are going to work for
Server Side Swift (i.e. how the API of the HTTP Request/Response body
streams would look like). That kinda ties into this.


Summary: The service object as you proposed should be fine as a support
wrapper used by higher level I/O objects. I guess it is the right way to go
to support various I/O styles. Just wrap OpenSSL and the macOS thing. Do
not add anything else.
But *if* we would get a proper (byte) streaming abstraction, I would prefer
if a TLS stream would live on top of this (be a stream itself and wrap the
stream representing the connection).

hh

> On 23 Mar 2017, at 16:52, Gelareh Taban <gtaban at us.ibm.com> wrote:
>
> Btw Helge, really interesting about the GCD channel APIs. How would your
propose they be integrated? Would they replace or modify onSend/onReceive
methods?

[attachment "signature.asc" deleted by Gelareh Taban/Austin/IBM]
_______________________________________________
swift-server-dev mailing list
swift-server-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170327/885f4c32/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170327/885f4c32/attachment.gif>