[swift-server-dev] HTTP Parser

Fri Nov 4 14:11:35 CDT 2016

Just to clarify, when I talk about Swift, I am absolutely not talking about
1:1 port. Rewriting C in Swift is pointless if we're not going to rethink
it for the language. If we collectively agree to use underlying C
libraries, then compiling them directly is my preference.

That said, even if we do end up doing that short term, I'd like to include
plans or at least intentions to do things in Swift. I (and I'm sure many of
us) generally prefer working in Swift because it's safe, succinct, and
clean. We also have several instances of existing HTTP parsers we could
pull from, it's not like we're starting from 0 as a group.

For HTTP2, I think everyone is in agreement that a c library is the way to
go. I'd like to give HTTP a bit more time for opinions to come in.

- Logan

On Fri, Nov 4, 2016 at 5:25 AM Alfredo Delli Bovi via swift-server-dev <
swift-server-dev at swift.org> wrote:

> Completely agree.
> Also, a poor performance at that stage of the request could lead to
> security issues too: i.e. DDoS attacks would be easier to execute.
> —
> Alfredo Delli Bovi
>
> On 4 Nov 2016, at 09:50, Samuel Kallner via swift-server-dev <
> swift-server-dev at swift.org> wrote:
>
> I agree with Paulo. One of Swift's strong points is its ability to bind
> with all sorts of existing "system" C based APIs. Especially C APIs that
> are extremely well tested and maintained. We should all remember that while
> many of us may have taken the http_parser from Node, Node itself took it
> from Nginx. This code comes with great pedigree.
>
> Why should we spend time developing an HTTP parser in Swift when we should
> be spending our collective time higher up the Web Server Framework
> toolchain? Alfredo Delli Bovi quoted the work that was done Dave Sperling
> to port the HTTP Parser Kitura was using to Swift. While he ported the
> code, he did not write the complete Unit Test Suite needed for that code.
> His own estimate was that writing the tests would be approximately two to
> three times the effort of the original port. I also seem to remember that
> the performance hit for that particular code was more than 33%.
>
> Another point, which is especially true on current Swift drivers, is that
> any code that is going to parse something like HTTP requests and responses
> is probably going to have to work at the byte level and not that String
> level. This is due to performance issues. At the byte level its actually a
> lot easier to write C code, than Swift code. This may change in the future,
> but lets wait until this kind of thing gets more performant in Swift.
>
> Some have said that readability is more important than performance. I for
> one, who have read the http_parser code from time to time, find rather
> readable for a tightly written finite state machine. Here I also beg to
> disagree that performance isn't important. In a server one wants to spend
> cycles doing real work for the requestor, not figuring out what he wants
> you to do. To scale one needs to be performant.
>
> Shmuel Kallner
> STSM Smart Client Platforms group
> Tel: +972-4829-6430
> e-mail: kallner at il.ibm.com
>
>
>
>
> From:        Paulo Faria via swift-server-dev <swift-server-dev at swift.org>
> To:        Logan Wright <logan at qutheory.io>
> Cc:        Swift Server Dev <swift-server-dev at swift.org>
> Date:        04/11/2016 00:15
> Subject:        Re: [swift-server-dev] HTTP Parser
> Sent by:        swift-server-dev-bounces at swift.org
> ------------------------------
>
>
>
> I think wrapping a battle-tested C library is the way to go. Using a C
> library is not the same as writing one. In our case we’ll have to deal with
> C APIs anyway (POSIX), so the experience won’t be something we’re not used
> to already. Pragmatically here are the pros and cons:
>
> Pros
> - Faster to wrap a C lib than to write everything in Swift
> - Safer to use a battle-tested C lib
> - Better performance when handling strings (major current bottleneck for
> Swift)
>
> Cons
> - We need the OK from Chris Lattner
> - If a bug is found we have to either:
>   - fix it ourselves and push back upstream
>   - if it’s something we don’t know how to fix we report and wait for the
> fix
>
> I’ve been using http_parser on Zewo for over an year and I haven’t found a
> single bug yet. That’s *very* unlikely to happen if we write a Swift parser
> ourselves.
>
> About the binary data discussion. I think something so important like that
> should reside in the standard library. I don’t think a protocol is a good
> idea because it promotes the creation of even more binary abstractions
> which is no good. I know the proposal of a new “data” type on the standard
> library falls on what I just said, *but* in a perfect world Foundation
> would lose NSData in favor of the standard library Data pretty much like it
> did for NSString/String. Eventually all other frameworks would be using
> standard library’s Data too.
>
> The feeling I got from Ted Kremenek is that we should picture the best
> scenario and then see where our work might land. This is the perfect case
> for that.
>
>
> On Nov 3, 2016, at 6:49 PM, Logan Wright via swift-server-dev <
> *swift-server-dev at swift.org* <swift-server-dev at swift.org>> wrote:
>
> Following up with what Tanner and Chris said. I think HTTP 2 is
> particularly difficult, and you're right chris, bringing in a c library,
> even if just temporarily will help expedite the process in an efficient way.
>
> I am however pretty ardently against porting C code to Swift as opposed to
> rethinking things for a Swift paradigm. If that's the case, I'd prefer to
> either link to the c code, or bring it into the Swift compiler. The end
> result would appear to be the same.
>
>  - Logan
>
> On Thu, Nov 3, 2016 at 4:46 PM Tanner Nelson via swift-server-dev <
> *swift-server-dev at swift.org* <swift-server-dev at swift.org>> wrote:
>
> Tanner Nelson
> Vapor
> *+1 (435) 773-2831* <(435)%20773-2831>
>
> On Nov 3, 2016, at 4:34 PM, Helge Heß via swift-server-dev <
> *swift-server-dev at swift.org* <swift-server-dev at swift.org>> wrote:
>
> On 3 Nov 2016, at 19:41, Alfredo Delli Bovi <*alfredo.dellibovi at gmail.com*
> <alfredo.dellibovi at gmail.com>> wrote:
> There has been some discussions about this in Kitura already (
> *https://github.com/IBM-Swift/Kitura-net/issues/52*
> <https://github.com/IBM-Swift/Kitura-net/issues/52>) and I think we can
> use what they found out at the moment.
> In my opinion, if we are not able to give the same (or better) performance
> we should go for a wrapper of a more performant lib, such as http_parser.
>
> They claim that their port is just ~1/3 slower, that seems perfectly
> reasonable to me. I’m all for using it.
>
> As far as I can tell, the package in question here is a carbon copy of the
> C parser (UnsafePointers, asserts, global funcs). The only difference is
> it's 1/3 slower.
>
> A big performance hit like that is not worth it unless we're getting
> improved readability or safety out of the code.
>
>
> I also agree with the overall sentiment that a ‘pure’ Swift solution
> should be preferred.
>
> Of course it’s also matter of the workload that have, we could always
> start with a wrapper, so we are able to define the APIs layer and ship a
> version with it and later on changing the implementation with a pure Swift.
>
> Yes, the API should sit on top of this and be essentially parser agnostic.
>
> hh
>
> _______________________________________________
> swift-server-dev mailing list
> *swift-server-dev at swift.org* <swift-server-dev at swift.org>
> *https://lists.swift.org/mailman/listinfo/swift-server-dev*
> <https://lists.swift.org/mailman/listinfo/swift-server-dev>
>
> _______________________________________________
> swift-server-dev mailing list
> *swift-server-dev at swift.org* <swift-server-dev at swift.org>
> *https://lists.swift.org/mailman/listinfo/swift-server-dev*
> <https://lists.swift.org/mailman/listinfo/swift-server-dev>
> _______________________________________________
> swift-server-dev mailing list
> *swift-server-dev at swift.org* <swift-server-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-server-dev
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
>
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
>
> _______________________________________________
> 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/20161104/ea986cd6/attachment.html>