[swift-server-dev] HTTP Parser

[Cătălin Stan]

Hi Guys,

I think it's also important to look a bit towards the future: the language will evolve. Performance bottlenecks that exist now will surely be over ome by future development. 

As far as the swift implementation's performance at this moment goes, I am actually in the process of rewritting Criollo (incl parser) entirely in Swift. (Objc & CFHTTPMessage now)

Cătălin 

Sent from my iPhone

> On Nov 3, 2016, at 19:51, Tanner Nelson via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> I think it's important to remember that performance is not the only concern.
> 
> If we need to use the node_http parser because of time constraints, I'd prefer that over creating a non-Swifty copy. If you want the functionality of UnsafePointers, C is the better language to be working in.
> 
> Going forward I think a Swifty HTTP parser could get decent performance. More importantly though it would be incredibly concise, readable, and maintainable.
> 
> Tanner Nelson
> Vapor 
> +1 (435) 773-2831
> 
>> On Nov 3, 2016, at 2:42 PM, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
>> 
>> Completely agree Alex, I also feel strongly about the language in general, and I think if we're going to take the time to build out Swift server apis, they should be in well, Swift.
>> 
>> In terms of performance, Swift will only continue to improve in performance, and given our access to the compiler team and the smart minds in this room. I think we can beat the node parser with time.
>> 
>> - Logan
>> 
>>> On Thu, Nov 3, 2016 at 2:41 PM Alfredo Delli Bovi <alfredo.dellibovi at gmail.com> wrote:
>>> Hi people,
>>> 
>>> There has been some discussions about this in Kitura already (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.
>>> 
>>> 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.
>>> 
>>> —
>>> Alfredo Delli Bovi 
>>> 
>>>> On 3 Nov 2016, at 19:35, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
>>>> 
>>>> Helge, definitely depends on the underlying network/dispatch scheme that we go with. I doubt we'd pull in my original code 1:1. But it does speak to my experience w/ the RFC spec in particular.
>>>> 
>>>> I'd personally opt for pure-swift over c-wrapper. I think it will be easier to maintain/deploy/optimize going forward. I don't have an inherent problem w/ the nodejs parser aside from that if people strongly prefer to use c-code here.
>>>> 
>>>> - Logan
>>>> 
>>>> On Thu, Nov 3, 2016 at 1:27 PM Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
>>>> Hi Logan,
>>>> 
>>>> On 03 Nov 2016, at 17:50, Logan Wright <logan at qutheory.io> wrote:
>>>> > Yup, you can see a lot of it in the underlying engine module from Vapor.
>>>> 
>>>> is it this one?:
>>>> 
>>>>   https://github.com/vapor/engine/blob/master/Sources/HTTP/Parser/HTTPParser.swift
>>>> 
>>>> that seems to be a pull based / blocking parser, right? That probably doesn’t work for a lot of environments.
>>>> 
>>>> 
>>>> Personally I’d suggest a small wrapper around this one:
>>>> 
>>>>   https://github.com/nodejs/http-parser
>>>> 
>>>> It is small, fast, highly efficient, zero copy, push based, supports chunked&upgrade and is extremely well tested and widely deployed.
>>>> 
>>>> 
>>>> I also did a straight port of that to Swift, though if you can use the C version I wouldn't use the port as it is significantly slower (and may have extra bugs introduced during the port):
>>>> 
>>>>   https://github.com/NozeIO/Noze.io/tree/master/Sources/http_parser
>>>> 
>>>> My approach here was to keep it close to the original, which makes for really ugly code :-)
>>>> I think it may be worthwhile to do another attempt of a port of the parser, but less 1:1 like mine, in a Swiftier way (the original uses a lot of goto’s :-).
>>>> 
>>>> 
>>>> As mentioned, I wouldn’t expect people to use the low level API but rather have nice objects filled by the underlying parser. What about `WORequest` & `WOResponse`? :-)
>>>> 
>>>> 
>>>> BTW: Something I consider important to discuss across all areas of interest (crypto, sockets, HTTP) is a protocol to represent a chunks of bytes and chunks of chunks of bytes (buckets and brigades in Apache terms). Of course that could be just NSData or DispatchData but I expect that some frameworks have their own way to represent such buffers, hence a protocol would be nice.
>>>> Why important? Well, because there needs to be a way to pass the data between those components w/o copying it :-)
>>>> 
>>>> hh
>>>> 
>>>> _______________________________________________
>>>> 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
> 
> _______________________________________________
> 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/20161103/a70036ca/attachment.html>