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

[Helge Heß]

On 27 Mar 2017, at 20:40, Gelareh Taban <gtaban at us.ibm.com> wrote:
> > 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)) -

NIO as in non-blocking I/O.

> how would this work in the context of Swift?

Presumably the demo would use DispatchIO and demonstrate the use of the client in the context of that.

> (that should also answer your question ;-)

Oh, you tried to be funny ;->

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

Sounds good. Do you have an example demonstrating the use of BlueSocket in NIO mode? Like a simple client which just opens a socket connection to a TLS server and reads with NIO configured.


> 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?

Well not specifically the class funcs, but yes, DispatchIO in stream mode:

  https://developer.apple.com/reference/dispatch/dispatchio.streamtype/1780994-stream
  https://developer.apple.com/reference/dispatch/dispatchio/1388941-read

>  How would it work with stream?

Not sure what you mean, a dispatch channel in stream mode *is* a stream to me :-) What do you mean by this? NSStream?

FYI: This has much more and is overkill for this thing here, but I did an implementation of a Node.js-style pull stream on top of DispatchIO, you can check it out here, etc:

  https://github.com/NozeIO/Noze.io/blob/master/Sources/streams/GReadableStreamType.swift#L68

Something like this, just optimised for byte streams would be cool (but maybe too opinionated). And I think that such a stream protocol could be kinda like DispatchIO channels.

Though I’m not sure though whether escaping closures are too much of a performance bottleneck and a delegate would be preferred.


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

I don’t think they are universally preferred as they may tie you into a specific IO dispatch approach. Some may want to do libmill, some DispatchIO, others plain Posix, and then some NIO. etc.


> What is tricky here is that Streams in (mac) Foundation has TLS support via property keys. 
> 
> https://developer.apple.com/reference/foundation/stream

I wasn’t referring to NSStream, but the concept of a stream in general. A stream would probably be a protocol (or multiple, read/write/duplex etc) which is then implemented by the TLS stream, the Socket, etc.


> 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?

Presumably you are primarily thinking NSStream here. I don’t know, maybe one can build on top of them, but I would prefer to build on top of GCD's channel API. Probably nothing really for the Server-Side-Swift effort though.

hh


> 
> 
> cheers,
> gelareh
> 
> 
> <graycol.gif>Helge Heß via swift-server-dev ---03/23/2017 11:53:37 AM---Hi Gelareh, I suppose what you have been saying about EAGAIN etc may work out. It would be really ni
> 
> 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
> 
> 
>