[swift-server-dev] Draft proposal for TLS Service APIs(pleasereview)
Helge Heß
me at helgehess.eu
Tue Mar 28 05:09:55 CDT 2017
On 28. Mar 2017, at 12:03, Johannes Weiß <johannesweiss at apple.com> wrote:
> Hi Helge and Gelareh,
>
>> [...]
>>> 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.
>
> as far as I understand the source code BlueSocket is blocking IO only. But its API basically breaks the abstraction by giving you (publically!) direct access to the the file descriptor.
>
> public internal(set) var socketfd: Int32 = SOCKET_INVALID_DESCRIPTOR
>
> (from: https://github.com/IBM-Swift/BlueSocket/blob/master/Sources/Socket.swift#L772 )
>
> so what you could do is
>
> fcntl(someBlueSocket.socketFD, O_NONBLOCK, 1)
>
> and then put in in a kqueue/epoll/DispatchSource . I personally don't think that counts as non-blocking API but it's possible :)
I think that this would actually be fine for a low level object.
But I’d like to see this working in the real world :-) The key part being that the TLS layer needs to buffer already read data until the TLS frames are complete. I know that this is possible with OpenSSL, and it was said that it should be possible with the low level macOS stuff, but I’d like to see this actually working. No offence, lets just make sure we don’t miss something in here as this is IMO very important.
hh
More information about the swift-server-dev
mailing list