Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

KORE – A fast SPDY-capable webserver for web development in C

kore.io

Post reply on HN
Print view View original

41–50 of 60 posts

Re: KORE – A fast SPDY-capable webserver for web development in C

#41

Post by lasercalm »

mpweiher wrote: post #24
a-priori wrote: post #13

Okay here's a peeve of mine: just because something is in C ("no overhead!") doesn't mean it's faster than something in another language in all situations. As an example, this server uses a thread pool architecture. This architecture will perform poorly with slow clients (common on the public Internet), servers which have to interact with slow disks or external services, and is useless for long-polling. It's only use…

> this server uses a thread pool architecture. Is the README wrong? It says: "Event driven architecture and worker processes for throughput" To me this indicates using events for the external interface (slow clients), and threads for taking advantage of multiple cores.

It looks like the README is accurate. A number of child processes are forked off and then event processing is done with kqueue on the BSD platform and epoll on Linux.

Re: KORE – A fast SPDY-capable webserver for web development in C

#43

Post by dschiptsov »

Ceased reading after mem.c - pool-based memory allocation which cache-locality awareness and data partitioning by access patterns is the must for a modern server. Just to malloc every buffer you need is a naive strategy, which, probably, will result in memory fragmentation and cache misses.

Surprisingly accurate and clean C. This guy is good one for hiring (assuming he wishes to be hired).

Re: KORE – A fast SPDY-capable webserver for web development in C

#44

Post by dcsommer »

thwarted wrote: post #40
dcsommer wrote: post #34

Earlier quoted context omitted.

Pipelining falls short of SPDY in several respects. The biggest problem is that it suffers from head of line blocking. One slow request or response prevents others from making progress.

This isn't a problem when the primary request is dynamic and served from one server/domain/connection and the remaining requests are for static assets stored on and served from another server/domain/connection.

Consider if the client makes a large POST followed by a few GETs. If the client has little upload bandwidth, the GETs will be delayed until the POST completes. With SPDY, they all can proceed concurrently. Similarly, if the client makes 5 GET requests, with the first being a heavy/slow/expensive resource for the server, the cheap resources can't be delivered until the slow resource finally is computed and returned.

Re: KORE – A fast SPDY-capable webserver for web development in C

#45

Post by akalin »

richo wrote: post #35
dcsommer wrote: post #33

Earlier quoted context omitted.

SPDY isn't necessarily insecure. Disabling header compression, for instance, works around the CRIME vulnerability.

Yeah, and if that didn't directly contravene SPDY's specification it'd be a great option: http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...

Disabling gzip compression isn't the only workaround to the CRIME attack. For Chromium, Adam Langley patched zlib to differentiate between various classes of data; see https://code.google.com/p/chromium/issues/detail?id=139744#c... and https://chromiumcodereview.appspot.com/10837057/ .

However, it's more difficult for other SPDY implementations to use the patched zlib, so this isn't an ideal solution. For SPDY/4 / HTTP/2, we will have a custom header compressor which is intended to eliminate CRIME-like attacks: https://tools.ietf.org/html/draft-ietf-httpbis-header-compre... .

(Disclaimer: I work on SPDY / HTTP/2 for Chromium.)

Re: KORE – A fast SPDY-capable webserver for web development in C

#46

Post by richo »

akalin wrote: post #45
richo wrote: post #35

Earlier quoted context omitted.

Yeah, and if that didn't directly contravene SPDY's specification it'd be a great option: http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...

Disabling gzip compression isn't the only workaround to the CRIME attack. For Chromium, Adam Langley patched zlib to differentiate between various classes of data; see https://code.google.com/p/chromium/issues/detail?id=139744#c... and https://chromiumcodereview.appspot.com/10837057/ . However, it's more difficult for other SPDY implementations to use the patched zlib, so this isn't an ideal solution. For SPDY/4 / HT…

I saw an awesome talk my mnot recently about http/2.0 for which I'm really excited. A large part of it was basically "Lessons we learned from SPDY" which is great, in the longterm.

Personally I feel SPDY was a huge benefit to the internet, but in saying that it was a huge benefit in the form of "a cautionary tale to others"

Re: KORE – A fast SPDY-capable webserver for web development in C

#47

Post by akalin »

osth wrote: post #39
dcsommer wrote: post #34

Earlier quoted context omitted.

Pipelining falls short of SPDY in several respects. The biggest problem is that it suffers from head of line blocking. One slow request or response prevents others from making progress.

I trust in theory this is true, but I've never personally observed this in practice. I guess SPDY fans' marketing of this "feature" would be more convincing if I could see a demonstration. I just don't see any noticeable delays when using pipelining. What strikes me as peculiar about the interest in SPDY is that I never saw any interest in pipelining before SPDY. And I really doubt it was because of potential head of…

HTTP pipelining is turned off by default in most browsers due to concerns with buggy proxies and servers (see https://bugzilla.mozilla.org/show_bug.cgi?id=264354 ). It may work for you and the particular set of servers you visit, but I suspect browser developers would rather have a browser that by default works with the widest possible range of configurations.

Unfortunately, it being turned off by default in most browsers means that most people won't see the benefits from it. Hopefully, the upcoming HTTP/2 standard will fare better (latest draft: https://tools.ietf.org/html/draft-unicorn-httpbis-http2-01 ).

Note that HTTP/2 will be based on SPDY (in particular, SPDY/4 with the new header compressor). Hopefully, when the standard is finalized and we have multiple strong implementations, that will allay the concerns you seem to have with SPDY today.

(Disclaimer: I work on SPDY / HTTP/2 for Chromium.)

Re: KORE – A fast SPDY-capable webserver for web development in C

#48

Post by pi18n »

drdaeman wrote: post #25
weland wrote: post #22

Earlier quoted context omitted.

It's quite a gift for embedded systems. It's very convenient to have a self-contained solution for a web interface, rather than drag an interpreter and a web server on an already crowded rootfs. Plus, you can get the benefit of static analysis and the like, which is extra useful on such systems.

I believe there are relatively many AOT-compiled-to-native-code languages other than C.

But have they equal tooling? That's why I'd be using C if I were using C for something; it's "portable assembly".

Re: KORE – A fast SPDY-capable webserver for web development in C

#49

Post by antihero »

fcambus wrote: post #23
eric_bullington wrote: post #20

Earlier quoted context omitted.

There is such a framework: openresty http://openresty.org/ It uses a wide range of 3rd-party nginx modules, and Lua as a scripting language, to form a nice little framework. Extraordinarily fast by any standards.

Lapis is also worth mentioning : http://leafo.net/lapis/ Lapis is a framework for building web applications using MoonScript (or Lua) that runs inside of a customized version of Nginx called OpenResty.

That looks really interesting, thanks.

Re: KORE – A fast SPDY-capable webserver for web development in C

#50

Post by osth »

akalin wrote: post #47
osth wrote: post #39

Earlier quoted context omitted.

I trust in theory this is true, but I've never personally observed this in practice. I guess SPDY fans' marketing of this "feature" would be more convincing if I could see a demonstration. I just don't see any noticeable delays when using pipelining. What strikes me as peculiar about the interest in SPDY is that I never saw any interest in pipelining before SPDY. And I really doubt it was because of potential head of…

HTTP pipelining is turned off by default in most browsers due to concerns with buggy proxies and servers (see https://bugzilla.mozilla.org/show_bug.cgi?id=264354 ). It may work for you and the particular set of servers you visit, but I suspect browser developers would rather have a browser that by default works with the widest possible range of configurations. Unfortunately, it being turned off by default in most bro…

Yes, I understand there are buggy servers and proxies... and I use a browser that has settings to accomodate them. However... I do not know about HTTP bugs that affect pipelining. And... in addition, for pipelining, I do not use a browser to do the initial retrieval. I use something like netcat to fetch and then I view the results with a browser.

Can you give me a list of buggy servers where my HTTP/1.1 pipelining will not work as desired? I've been doing pipelining for 10 years (that's quite a few servers I've tried) with no problems.

The arguments made by SPDY fans (e.g. Google employees) all seem plausible. But I wonder why they are never supported by evidence? IOW, please show me, don't just tell me. SPDY seems to solve "problems" I'm not having. Where can I see these HTTP/1.1 pipelining problems (not just problems with browsers like Firefox or Chrome) in action? I'd love to try some of the buggy servers you allude to and see if they slow down pipelining with netcat.

Post reply on HN