[swift-server-dev] Sockets API

[Paulo Faria]

I think a very good reference for the conversation regarding concurrency is libdill:

https://github.com/sustrik/libdill <https://github.com/sustrik/libdill>

And dsock:

https://github.com/sustrik/dsock <https://github.com/sustrik/dsock>

dosck has a work-in-progress RFC:

https://github.com/sustrik/dsock/blob/master/rfc/sock-api-revamp-01.txt <https://github.com/sustrik/dsock/blob/master/rfc/sock-api-revamp-01.txt>

Libdill's biggest concept is structured concurrency:

http://libdill.org/structured-concurrency.html <http://libdill.org/structured-concurrency.html>

libdill is an elegant solution for one of the biggest problems of concurrency, cancelation.
It uses coroutines, procs and CSP to deal with communication.
On the other hand dsock solves the problem of protocol composition. The RFC explains
the concept in great detail. I really love the approach and I think we can get a lot of
inspiration from these sources.

> On Oct 27, 2016, at 9:27 PM, Michael Chiu via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> On 27 Oct 2016, at 15:27:56 CDT 2016, Helge Heß <me at helgehess.eu <http://helgehess.eu/>> wrote:
> > 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. 
> I think one of the reason why common socket api is necessary since socket is not standardized across platforms (WINSOCK, BSD Socket, Linux Socket…) at all. 
> Another reason is probably because of the sockaddr struct family. They have different sizes, different alignment(on different os), often need to cast the pointer around, and incredibly hard to use in pure swift manner. 
> Nevertheless I think swift is a great language for both high and low level programming, if we have some swift-like yet low level api we essentially open up the opportunities for other developers.
>  
> > A framework choosing a custom event loop certainly can work just fine today with the Posix functions available?
> I’m not quite sure what you mean here.
> > 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.
> 
> Sorry for my bad explanation, override is definitely not a good word choice. What I mean is 
> 
>     protocol Readable {
>         func read() -> Data?// how do we read
>    }
> 
>    protocol Writable {
>         func write(data: Data) // how do we write (send, sendfile, …) 
>    } 
> 
>    protocol Socket: Readable, Writable {}
> 
> so we can easily make something like:
> 
> class TLSSocket: Socket {
>     func read() -> Data? {
>     … ssl_read….
>     }
>     func write(data: Data) {
>     … ssl_write….
>     }    
> }
> 
> such that we can easily implement low level optimization and extent to different socket interfaces.
> 
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161028/ca50c913/attachment.html>