<html><body><p><tt><font size="2">Hi Helge,</font></tt><br><tt><font size="2">sorry for the delayed response.</font></tt><br><br><tt><font size="2">> I suppose what you have been saying about EAGAIN etc may work out. </font></tt><br><tt><font size="2">> It would be really nice to actually try the API with an NIO consumer, did you do this already? </font></tt><br><tt><font size="2">> Just to make sure and test out that we aren’t missing something.<br></font></tt><br><tt><font size="2">What is an NIO consumer? I see that Java has New I/O (</font></tt><a href="https://en.wikipedia.org/wiki/New_I/O_(Java)"><tt><font size="2">https://en.wikipedia.org/wiki/New_I/O_(Java)</font></tt></a><tt><font size="2">) - how would this work in the context of Swift?</font></tt><br><br><tt><font size="2">(that should also answer your question ;-)</font></tt><br><br><tt><font size="2">If you are talking about non-blocking by any chance, we have an implementation of this in BlueSSLService (</font></tt><a href="https://github.com/IBM-Swift/BlueSSLService"><tt><font size="2">https://github.com/IBM-Swift/BlueSSLService</font></tt></a><tt><font size="2">) which interfaces with a socket management layer (BlueSocket - </font></tt><a href="https://github.com/IBM-Swift/BlueSocket"><tt><font size="2">https://github.com/IBM-Swift/BlueSocket</font></tt></a><tt><font size="2">). </font></tt><br><br><tt><font size="2">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.</font></tt><br><br><tt><font size="2"><br><br>> Wrt the GCD channel stuff. Well, your design has that separate service object which is ‘used' by some ‘Socket’ class. </font></tt><br><tt><font size="2">> With GCD in mind I would design the TLS support as a new custom channel which is just wrapping a GCD channel. </font></tt><br><tt><font size="2">> It would provide the same API like GCD plus the necessary extras. Kinda like OpenSSL BIOs, just with async.<br><br>> But this would tie the I/O to a GCD API style (not necessarily to GCD, you could factor out the channel API </font></tt><br><tt><font size="2">> as a ’stream' protocol). Quite likely this is still not desirable for everyone.<br></font></tt><br><tt><font size="2">Really interesting. Dispatch IO has:</font></tt><br><br><a href="https://developer.apple.com/reference/dispatch/dispatchio"><tt><font size="2">https://developer.apple.com/reference/dispatch/dispatchio</font></tt></a><br><tt><font size="2">class func read(fromFileDescriptor: Int32, maxLength: Int, runningHandlerOn queue: DispatchQueue, handler: @escaping (DispatchData, Int32) -> Void)</font></tt><br><tt><font size="2">class func write(toFileDescriptor: Int32, data: DispatchData, runningHandlerOn queue: DispatchQueue, handler: @escaping (DispatchData?, Int32) -> Void)</font></tt><br><br><tt><font size="2">Are you talking about these APIs? How would it work with stream?</font></tt><br><br><tt><font size="2"><br><br>> I haven’t seen a proposal on how (byte) streams are going to work for Server Side Swift </font></tt><br><tt><font size="2">> (i.e. how the API of the HTTP Request/Response body streams would look like). That kinda ties into this.<br><br><br>> Summary: The service object as you proposed should be fine as a support wrapper used by higher level </font></tt><br><tt><font size="2">> I/O objects. I guess it is the right way to go to support various I/O styles. Just wrap OpenSSL and </font></tt><br><tt><font size="2">> the macOS thing. Do not add anything else.<br>> But *if* we would get a proper (byte) streaming abstraction, I would prefer if a TLS stream would </font></tt><br><tt><font size="2">> live on top of this (be a stream itself and wrap the stream representing the connection).<br></font></tt><br><br><tt><font size="2">I agree about the stream abstraction. In order for us to completely abstract away the transport layer, streams are ideal and preferred. </font></tt><br><br><tt><font size="2">What is tricky here is that Streams in (mac) Foundation has TLS support via property keys. </font></tt><br><br><a href="https://developer.apple.com/reference/foundation/stream"><tt><font size="2">https://developer.apple.com/reference/foundation/stream</font></tt></a><br><br><tt><font size="2">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.<br></font></tt><br><tt><font size="2">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?</font></tt><br><br><br><tt><font size="2">cheers,</font></tt><br><tt><font size="2">gelareh</font></tt><br><br><br><img width="16" height="16" src="cid:1__=8FBB0A7FDFFE673E8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Helge Heß via swift-server-dev ---03/23/2017 11:53:37 AM---Hi Gelareh, I suppose what you have been s"><font size="2" color="#424282">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</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Helge Heß via swift-server-dev <swift-server-dev@swift.org></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">swift-server-dev <swift-server-dev@swift.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">03/23/2017 11:53 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [swift-server-dev] Draft proposal for TLS Service APIs (pleasereview)</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">swift-server-dev-bounces@swift.org</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">Hi Gelareh,<br><br>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.<br><br><br>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.<br><br>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.<br><br><br>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.<br><br><br>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.<br>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).<br><br>hh<br><br>> On 23 Mar 2017, at 16:52, Gelareh Taban <gtaban@us.ibm.com> wrote:<br>> <br>> Btw Helge, really interesting about the GCD channel APIs. How would your propose they be integrated? Would they replace or modify onSend/onReceive methods?<br><br>[attachment "signature.asc" deleted by Gelareh Taban/Austin/IBM] _______________________________________________<br>swift-server-dev mailing list<br>swift-server-dev@swift.org<br></font></tt><tt><font size="2"><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev">https://lists.swift.org/mailman/listinfo/swift-server-dev</a></font></tt><tt><font size="2"><br></font></tt><br><br><BR>
</body></html>