[swift-server-dev] Sockets API

[Helge Heß]

On 27 Oct 2016, at 21:07, Michael Chiu <hatsuneyuji at icloud.com> wrote:
> I have some thought about how socket should be implemented.
> 
> I think libdispatch is maybe too high-level if we are working on a socket framework we should work on just socket for the following reasons:
> 
> 1. It take care of too many things.
> 
> Most of the framework exist today using different event-looping/threading model.

I can see (and essentially agree) with your point, but then I’m also back at wondering why there is a need for a common socket API at _such_ a low level. A framework choosing a custom event loop certainly can work just fine today with the Posix functions available?

My thinking was that GCD is the ‘Swifty’ thing for doing event-looping/threading and hence would be a basis for this (and the related HTTP server module). But I wasn’t sure, hence my point 1).


> 2.  libdispatch make it hard to implement some protocols such as TLS, where you delegate the TLS frameworks(openssl/libressl) to handle TLS handshake, sending/writing. These frameworks require a real file descriptor to work.

I don’t want to say anything wrong as I haven’t looked at it for a very long time, but 'These frameworks require a real file descriptor to work’ sounds incorrect to me. The way I remember OpenSSL is that you can wrap the underlying transport in a BIO and have TLS sit on top of this.
Maybe you have the time to elaborate.


> 3. I think the a fundamental socket framework should not use either delegate nor closure, but a overridable read() -> Data and write() function instead. Socket in general has a pretty short lifetime, if we use closure and delegate it will be harder to manage the lifetime of related objects. Such as if I open a separate unix socket to connect to some database, however the network socket closed before the response from database socket even arrived.

I don’t understand what you are saying here :-) Are you just describing an abstract Socket base class which has a ‘RawSocket’ subclass in which read/write is directly invoking Posix.read/write and a ‘SSLSocket’ subclass which has another implementation of that dealing with the encryption?
Or do you really want to subclass a socket in say a PostgreSQLSocket and then override a function like `handleData(…)`. That would sound wrong to me. A PGConnection should interact using a socket object, but not inherit from one.

(Just to be clear: my delegate/closure point was only related to the case in which the socket would be _asynchronous_. In other words this was about how an async socket would deliver data back to the client.)


> I think we can take advantage of swift as a protocol oriented language and make a “SocketType” protocol

I expect that there would definitely be something like that (with the note that I think Swift 3 doesn’t call protocol `xyzType` anyone, but just `xyz` or `Socket` in this case :-)

And my question in 3) was whether we would have just `SocketType` or more like a:

  protocol InputStream  {}          // read-like stuff
  protocol OutputStream {}          // write-like stuff
  protocol DuplexStream : InputStream, OutputStream
  protocol Socket : DuplexStream {} // adds timeouts and such

Considering that a lot of OpenSSL stuff (hashing, encryption etc) and other parsing code is desirable not just for sockets, but also for files and other byte based data.

hh