<div style="font:14px/1.5 'Lucida Grande', '微软雅黑';color:#333;"><p style="font:14px/1.5 'Lucida Grande';margin:0;"><br></p><span style="font: 14px/1.5 'Lucida Grande';color:#333;">Hi all:</span><div><span style="font: 14px/1.5 'Lucida Grande';color:#333;"><br></span></div><div style="orphans: 2; widows: 2;"><span style="font: 14px/1.5 'Lucida Grande';color:#333;">I know a wonderful socket library nanomsg </span><a href="https://github.com/nanomsg/nanomsg" style="font-family: 'Lucida Grande';">https://github.com/nanomsg/nanomsg</a>. It has friendly interface, <span style="font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; orphans: 2; widows: 2;">high performance, </span>platform<span style="font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; orphans: 2; widows: 2;"> </span>independent<span style="font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; orphans: 2; widows: 2;">, and </span>scalable of adding protocol<font face="-apple-system, BlinkMacSystemFont, Segoe UI, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol"><span style="font-size: 16px;">.</span></font></div><div style="orphans: 2; widows: 2;"><br></div><div><div class="foxmail_blockquote_fromhere_element" style="font: 12px/1.5 'Lucida Grande';padding:2px 0 2px 0;"><span style="color:#333;text-decoration:line-through;white-space:pre-wrap;"> </span> 原始邮件 <span style="color:#333;text-decoration:line-through;white-space:pre-wrap;"> </span></div><div style="font: 12px/1.5 'Lucida Grande';background:#efefef;color:#666666;padding:8px;"><div><b style="color:#999;">发件人:</b> swift-server-dev-request<swift-server-dev-request@swift.org></div><div><b style="color:#999;">收件人:</b> swift-server-dev<swift-server-dev@swift.org></div><div><b style="color:#999;">发送时间:</b> 2016年10月30日(周日) 01:00</div><div><b style="color:#999;">主题:</b> swift-server-dev Digest, Vol 1, Issue 4</div></div><br><div class="mail_quote_79F8204C72294B6788F04B7A7378E992" style="font: 14px/1.5 'Lucida Grande';color:#333;"><pre style="white-space:pre-wrap;">Send swift-server-dev mailing list submissions to
<a href="mailto:swift-server-dev@swift.org" title="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>
To subscribe or unsubscribe via the World Wide Web, visit
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" title="https://lists.swift.org/mailman/listinfo/swift-server-dev">https://lists.swift.org/mailman/listinfo/swift-server-dev</a>
or, via email, send a message with subject or body 'help' to
<a href="mailto:swift-server-dev-request@swift.org" title="mailto:swift-server-dev-request@swift.org">swift-server-dev-request@swift.org</a>
You can reach the person managing the list at
<a href="mailto:swift-server-dev-owner@swift.org" title="mailto:swift-server-dev-owner@swift.org">swift-server-dev-owner@swift.org</a>
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 <<a href="mailto:james.lei65@gmail.com" title="mailto:james.lei65@gmail.com">james.lei65@gmail.com</a>>
To: <a href="mailto:swift-server-dev@swift.org" title="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>
Subject: [swift-server-dev] Zero-copy/Zero memory allocation
networking
Message-ID:
<<a href="mailto:CAB-Y3Ch4f9GrrYf0-yK=nZLSwxKWdCCWRCzMd=vXh0Lw8uXoGw@mail.gmail.com" title="mailto:CAB-Y3Ch4f9GrrYf0-yK=nZLSwxKWdCCWRCzMd=vXh0Lw8uXoGw@mail.gmail.com">CAB-Y3Ch4f9GrrYf0-yK=nZLSwxKWdCCWRCzMd=vXh0Lw8uXoGw@mail.gmail.com</a>>
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: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161028/92ec3b60/attachment-0001.html>" title="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161028/92ec3b60/attachment-0001.html>">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161028/92ec3b60/attachment-0001.html></a>
------------------------------
Message: 2
Date: Fri, 28 Oct 2016 15:56:48 -0700
From: Daniel Dunbar <<a href="mailto:daniel_dunbar@apple.com" title="mailto:daniel_dunbar@apple.com">daniel_dunbar@apple.com</a>>
To: Helge Heß <<a href="mailto:me@helgehess.eu" title="mailto:me@helgehess.eu">me@helgehess.eu</a>>
Cc: Swift Server Dev <<a href="mailto:swift-server-dev@swift.org" title="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>>
Subject: Re: [swift-server-dev] Posix Module
Message-ID: <<a href="mailto:9D60A63D-0822-4F2D-8B44-EC7BAE27C121@apple.com" title="mailto:9D60A63D-0822-4F2D-8B44-EC7BAE27C121@apple.com">9D60A63D-0822-4F2D-8B44-EC7BAE27C121@apple.com</a>>
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 <<a href="mailto:swift-server-dev@swift.org" title="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>> 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 :-)
>
> <a href="https://github.com/NozeIO/Noze.io/tree/master/Sources/xsys" title="https://github.com/NozeIO/Noze.io/tree/master/Sources/xsys">https://github.com/NozeIO/Noze.io/tree/master/Sources/xsys</a>
>
> Or is there a better way to do this already?
>
> Thanks,
> Helge
>
> _______________________________________________
> swift-server-dev mailing list
> <a href="mailto:swift-server-dev@swift.org" title="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>
> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" title="https://lists.swift.org/mailman/listinfo/swift-server-dev">https://lists.swift.org/mailman/listinfo/swift-server-dev</a>
------------------------------
Message: 3
Date: Fri, 28 Oct 2016 20:58:15 -0200
From: Paulo Faria <<a href="mailto:paulo@zewo.io" title="mailto:paulo@zewo.io">paulo@zewo.io</a>>
To: Michael Chiu <<a href="mailto:hatsuneyuji@icloud.com" title="mailto:hatsuneyuji@icloud.com">hatsuneyuji@icloud.com</a>>
Cc: <a href="mailto:swift-server-dev@swift.org" title="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>
Subject: Re: [swift-server-dev] Sockets API
Message-ID: <<a href="mailto:182C0182-8BE6-41B4-994E-B91067DFE14C@zewo.io" title="mailto:182C0182-8BE6-41B4-994E-B91067DFE14C@zewo.io">182C0182-8BE6-41B4-994E-B91067DFE14C@zewo.io</a>>
Content-Type: text/plain; charset="utf-8"
I think a very good reference for the conversation regarding concurrency is libdill:
<a href="https://github.com/sustrik/libdill" title="https://github.com/sustrik/libdill">https://github.com/sustrik/libdill</a> <<a href="https://github.com/sustrik/libdill>" title="https://github.com/sustrik/libdill>">https://github.com/sustrik/libdill></a>
And dsock:
<a href="https://github.com/sustrik/dsock" title="https://github.com/sustrik/dsock">https://github.com/sustrik/dsock</a> <<a href="https://github.com/sustrik/dsock>" title="https://github.com/sustrik/dsock>">https://github.com/sustrik/dsock></a>
dosck has a work-in-progress RFC:
<a href="https://github.com/sustrik/dsock/blob/master/rfc/sock-api-revamp-01.txt" title="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</a> <<a href="https://github.com/sustrik/dsock/blob/master/rfc/sock-api-revamp-01.txt>" title="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></a>
Libdill's biggest concept is structured concurrency:
<a href="http://libdill.org/structured-concurrency.html" title="http://libdill.org/structured-concurrency.html">http://libdill.org/structured-concurrency.html</a> <<a href="http://libdill.org/structured-concurrency.html>" title="http://libdill.org/structured-concurrency.html>">http://libdill.org/structured-concurrency.html></a>
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 <<a href="mailto:swift-server-dev@swift.org" title="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>> wrote:
>
> On 27 Oct 2016, at 15:27:56 CDT 2016, Helge Heß <me at helgehess.eu <<a href="http://helgehess.eu/>>" title="http://helgehess.eu/>>">http://helgehess.eu/>></a> 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
> <a href="mailto:swift-server-dev@swift.org" title="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>
> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" title="https://lists.swift.org/mailman/listinfo/swift-server-dev">https://lists.swift.org/mailman/listinfo/swift-server-dev</a>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161028/ca50c913/attachment-0001.html>" title="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161028/ca50c913/attachment-0001.html>">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161028/ca50c913/attachment-0001.html></a>
------------------------------
Message: 4
Date: Sat, 29 Oct 2016 01:06:38 +0200
From: Helge Heß <<a href="mailto:me@helgehess.eu" title="mailto:me@helgehess.eu">me@helgehess.eu</a>>
To: Swift Server Dev <<a href="mailto:swift-server-dev@swift.org" title="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>>
Subject: Re: [swift-server-dev] Sockets API
Message-ID: <<a href="mailto:F94E8DAD-640B-480F-8CFB-3EF3EC3E48A6@helgehess.eu" title="mailto:F94E8DAD-640B-480F-8CFB-3EF3EC3E48A6@helgehess.eu">F94E8DAD-640B-480F-8CFB-3EF3EC3E48A6@helgehess.eu</a>>
Content-Type: text/plain; charset=utf-8
On 28 Oct 2016, at 01:27, Michael Chiu via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" title="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>> 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:
<a href="http://svn.opengroupware.org/SOPE/branches/sope-4.6/sope-core/NGStreams/NGSocket.m" title="http://svn.opengroupware.org/SOPE/branches/sope-4.6/sope-core/NGStreams/NGSocket.m">http://svn.opengroupware.org/SOPE/branches/sope-4.6/sope-core/NGStreams/NGSocket.m</a>
and another one:
<a href="https://github.com/opensource-apple/CF/blob/master/CFSocket.c" title="https://github.com/opensource-apple/CF/blob/master/CFSocket.c">https://github.com/opensource-apple/CF/blob/master/CFSocket.c</a>
> 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:
<a href="https://github.com/AlwaysRightInstitute/SwiftSockets/blob/master/Sources/SwiftSockets/SocketAddress.swift" title="https://github.com/AlwaysRightInstitute/SwiftSockets/blob/master/Sources/SwiftSockets/SocketAddress.swift">https://github.com/AlwaysRightInstitute/SwiftSockets/blob/master/Sources/SwiftSockets/SocketAddress.swift</a>
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 <<a href="mailto:hatsuneyuji@icloud.com" title="mailto:hatsuneyuji@icloud.com">hatsuneyuji@icloud.com</a>>
To: Helge Heß <<a href="mailto:me@helgehess.eu" title="mailto:me@helgehess.eu">me@helgehess.eu</a>>
Cc: <a href="mailto:swift-server-dev@swift.org" title="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>
Subject: Re: [swift-server-dev] Sockets API
Message-ID: <<a href="mailto:A7BFBDD2-1019-46DA-BA99-786BB1B494D1@icloud.com" title="mailto:A7BFBDD2-1019-46DA-BA99-786BB1B494D1@icloud.com">A7BFBDD2-1019-46DA-BA99-786BB1B494D1@icloud.com</a>>
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: <a href="https://github.com/projectSX0/spartanX/blob/master/Sources/SXSocketAddress.swift" title="https://github.com/projectSX0/spartanX/blob/master/Sources/SXSocketAddress.swift">https://github.com/projectSX0/spartanX/blob/master/Sources/SXSocketAddress.swift</a> <<a href="https://github.com/projectSX0/spartanX/blob/master/Sources/SXSocketAddress.swift>." title="https://github.com/projectSX0/spartanX/blob/master/Sources/SXSocketAddress.swift>.">https://github.com/projectSX0/spartanX/blob/master/Sources/SXSocketAddress.swift>.</a>
> 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: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161028/69c92438/attachment-0001.html>" title="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161028/69c92438/attachment-0001.html>">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161028/69c92438/attachment-0001.html></a>
------------------------------
_______________________________________________
swift-server-dev mailing list
<a href="mailto:swift-server-dev@swift.org" title="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" title="https://lists.swift.org/mailman/listinfo/swift-server-dev">https://lists.swift.org/mailman/listinfo/swift-server-dev</a>
End of swift-server-dev Digest, Vol 1, Issue 4
**********************************************
</pre></div></div></div>