[swift-server-dev] 回复：swift-server-dev Digest, Vol 1, Issue 4 About Sockets API

a a at swiftc.org
Sat Oct 29 23:04:58 CDT 2016 

Hi all:


I know a wonderful socket library nanomsghttps://github.com/nanomsg/nanomsg. It has friendly interface,high performance,platformindependent, andscalable of adding protocol.


原始邮件
发件人:swift-server-dev-requestswift-server-dev-request at swift.org
收件人:swift-server-devswift-server-dev at swift.org
发送时间:2016年10月30日(周日) 01:00
主题:swift-server-dev Digest, Vol 1, Issue 4


Send swift-server-dev mailing list submissions to swift-server-dev at swift.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.swift.org/mailman/listinfo/swift-server-dev or, via email, send a message with subject or body 'help' to swift-server-dev-request at swift.org You can reach the person managing the list at swift-server-dev-owner at swift.org When replying, please edit your Subject line so it is more specific than "Re: Contents of swift-server-dev digest..." Today's Topics: 1. Zero-copy/Zero memory allocation networking (Muse M) 2. Re: Posix Module (Daniel Dunbar) 3. Re: Sockets API (Paulo Faria) 4. Re: Sockets API (Helge Heß) 5. Re: Sockets API (Michael Chiu) ---------------------------------------------------------------------- Message: 1 Date: Fri, 28 Oct 2016 23:13:28 +0800 From: Muse M james.lei65 at gmail.com To: swift-server-dev at swift.org Subject: [swift-server-dev] Zero-copy/Zero memory allocation networking Message-ID: CAB-Y3Ch4f9GrrYf0-yK=nZLSwxKWdCCWRCzMd=vXh0Lw8uXoGw at mail.gmail.com Content-Type: text/plain; charset="utf-8" I can see there are way to achieve more performance and save resource with zero-copy on data transfer, serving or transform. Fasthttp written in Go is one of an example. The idea would be benefits for embedded device and reduce power consumption especially more resources can be save for other purpose e.g. database, crypto, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.swift.org/pipermail/swift-server-dev/attachments/20161028/92ec3b60/attachment-0001.html ------------------------------ Message: 2 Date: Fri, 28 Oct 2016 15:56:48 -0700 From: Daniel Dunbar daniel_dunbar at apple.com To: Helge Heß me at helgehess.eu Cc: Swift Server Dev swift-server-dev at swift.org Subject: Re: [swift-server-dev] Posix Module Message-ID: 9D60A63D-0822-4F2D-8B44-EC7BAE27C121 at apple.com Content-Type: text/plain; charset=utf-8 Given the Glibc overlay lives in Swift, this probably is more appropriate for swift-dev rather than the server APIs project specifically. - Daniel  On Oct 28, 2016, at 8:51 AM, Helge Heß via swift-server-dev swift-server-dev at swift.org wrote:   Hi,   I guess this kinda belongs here:   I wonder whether we can have a standard Posix module with all the standard Posix stuff in it to avoid the   #if os(Linux)  import Glibc  #else  import Darwin  #endif   for things which are standardised in Posix (and hence the same, even on Windoze). I currently have an `xsys` module to alias the definitions, but this is kinda crap :-)   https://github.com/NozeIO/Noze.io/tree/master/Sources/xsys   Or is there a better way to do this already?   Thanks,  Helge   _______________________________________________  swift-server-dev mailing list  swift-server-dev at swift.org  https://lists.swift.org/mailman/listinfo/swift-server-dev ------------------------------ Message: 3 Date: Fri, 28 Oct 2016 20:58:15 -0200 From: Paulo Faria paulo at zewo.io To: Michael Chiu hatsuneyuji at icloud.com Cc: swift-server-dev at swift.org Subject: Re: [swift-server-dev] Sockets API Message-ID: 182C0182-8BE6-41B4-994E-B91067DFE14C at zewo.io Content-Type: text/plain; charset="utf-8" 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-0001.html ------------------------------ Message: 4 Date: Sat, 29 Oct 2016 01:06:38 +0200 From: Helge Heß me at helgehess.eu To: Swift Server Dev swift-server-dev at swift.org Subject: Re: [swift-server-dev] Sockets API Message-ID: F94E8DAD-640B-480F-8CFB-3EF3EC3E48A6 at helgehess.eu Content-Type: text/plain; charset=utf-8 On 28 Oct 2016, at 01:27, 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 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. You need to elaborate a little more. “is not standardised across platforms at all”. In my eyes the reverse is true, the socket API *is* standardised by Posix and even Winsock2 is virtually identical to the Unix one (being just a Windows port of the BSD one). Yes there are a lot of small differences and various extensions, but nothing fundamental unless you want to get really advanced. Here is a very old socket imp which works on all three platforms: http://svn.opengroupware.org/SOPE/branches/sope-4.6/sope-core/NGStreams/NGSocket.m and another one: https://github.com/opensource-apple/CF/blob/master/CFSocket.c  Another reason is probably because of the sockaddr struct family. They have different sizes, different alignment(on different os), Differences in size and alignment are completely handled by the clang C mapping and of no concern at all to the user of those structs?  often need to cast the pointer around, and incredibly hard to use in pure swift manner. Absolutely, the raw structs are hard to use as-is. But since you can extend C structs in Swift you can make them really nice. Look at this as an example: https://github.com/AlwaysRightInstitute/SwiftSockets/blob/master/Sources/SwiftSockets/SocketAddress.swift it lets you do stuff like: let addr : sockaddr_in = “127.0.0.1:80” or iterate through `addrinfo` since they are made conforming to the `Sequence` protocol, etc. And all that w/o actually wrapping the structs in yet another construct. Want a swiftier name for them? `typealias IPv4SocketAddress = sockaddr_in` does the trick ;-) Note: I don’t want to push this as the ‘one’ solution the working group should use. But it actually is pretty similar to how other C-APIs (like CoreGraphics) are ‘Swifty'fied’. C based stuff doesn’t have to look bad in Swift, you can make that really nice. Just saying (and providing demo code demonstrating the fact ;-))   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 meant that if you are working at such a low level that you are selecting your own runloop and scheduling mechanism (instead of using the builtin one), working with the Posix socket APIs should be no big deal.  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. Yes, agreed. There should be protocols for such stuff. What is your opinion on my point:  3) Do you really want just a Socket, or is what you really want  a (byte) stream framework? hh ------------------------------ Message: 5 Date: Fri, 28 Oct 2016 17:45:24 -0700 From: Michael Chiu hatsuneyuji at icloud.com To: Helge Heß me at helgehess.eu Cc: swift-server-dev at swift.org Subject: Re: [swift-server-dev] Sockets API Message-ID: A7BFBDD2-1019-46DA-BA99-786BB1B494D1 at icloud.com Content-Type: text/plain; charset="utf-8"  You need to elaborate a little more. “is not standardised across platforms at all”. In my eyes the reverse is true, the socket API *is* standardised by Posix and even Winsock2 is virtually identical to the Unix one (being just a Windows port of the BSD one).  Yes there are a lot of small differences and various extensions, but nothing fundamental unless you want to get really advanced. The sockaddr part is definitely not standardized, and that is what I really mean since sockaddr is almost unavoidable when using socket. If sockaddr is not standardized, socket is not standardized. I apologize for not making myself clear.  Differences in size and alignment are completely handled by the clang C mapping and of no concern at all to the user of those structs? Not when in when BSD has 104 bytes in sockaddr_un.sun_path and Linux has 104. Plus BSD has extra sa_len component.  Absolutely, the raw structs are hard to use as-is. But since you can extend C structs in Swift you can make them really nice. I agree with you, that’s why we should include in the api. This is my implementation (sockaddr family as enums) btw: https://github.com/projectSX0/spartanX/blob/master/Sources/SXSocketAddress.swift https://github.com/projectSX0/spartanX/blob/master/Sources/SXSocketAddress.swift.  Yes, agreed. There should be protocols for such stuff. What is your opinion on my point:   3) Do you really want just a Socket, or is what you really want   a (byte) stream framework? I’ll say I think just socket, my overall approach is, make an independent layer for socket. Then after all if we decide to build default stream framework/event looping as well, we can simply build it separately and make socket compatible with it. If we going to need socket anyway, why don’t we open up more opportunities for developers as well? Off topic: Can you cc me a copy as well when you reply? Since somehow I can only see your response and reply manually from Archive, and I’d like to discuss with you more. Sincerely, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.swift.org/pipermail/swift-server-dev/attachments/20161028/69c92438/attachment-0001.html ------------------------------ _______________________________________________ swift-server-dev mailing list swift-server-dev at swift.org https://lists.swift.org/mailman/listinfo/swift-server-dev End of swift-server-dev Digest, Vol 1, Issue 4 **********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161030/26d9b797/attachment.html>

More information about the swift-server-dev mailing list