[swift-server-dev] Sockets API

Helge Heß me at helgehess.eu
Thu Oct 27 15:27:56 CDT 2016


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



More information about the swift-server-dev mailing list