8 ms·
KORE – A fast SPDY-capable webserver for web development in C
- X4 13y agoEvery new HTTP Daemon is heartly welcome!
- kaoD 13y agoIt's ironic that the website isn't working. Alternate link? (GitHub perhaps?)
- bobol 13y agohttps://github.com/jorisvink/kore https://github.com/jorisvink/kore
- alepper 13y agoLooks to have returned. (https://kore.io https://kore.io for those coming now that the top link has changed.) Also see: https://github.com/jorisvink/kore/commit/e1183e22a6a7a970213bef80032275c2e18521cf https://github.com/jorisvink/kore/commit/e1183e22a6a7a970213...
- bobol 13y agoConnection timeout? Brilliant idea, I especially love the SSL only. The web needs to move to pure SSL.
- davis_m 13y agoThat is a by-product of being SPDY compliant. The SPDY spec doesn't allow for unencrypted traffic, which is just one reason we need to switch over.
- anuragramdasan 13y agoWeb development in C, I love this.
- ndesaulniers 13y agoIt's just a server. Many sites sit behind nginx, a web server also written in C, as a reverse proxy but that doesn't make them "web development in C." Edit: This is web development in C: https://github.com/jorisvink/kore_website/blob/master/src/site.c https://github.com/jorisvink/kore_website/blob/master/src/si...
- alkou 13y agoDo you have any benchmarks against nginx? http://nginx.org/en/docs/http/ngx_http_spdy_module.html http://nginx.org/en/docs/http/ngx_http_spdy_module.html
- nvartolomei 13y agoTake libuv > WIN, to watch http://vimeo.com/24713213 http://vimeo.com/24713213. Libuv is used in nodejs.
- betterunix 13y agoWhy web development in C? Seems like a headache.
- m0nastic 13y ago"Why server-side development in Javascript? Seems like a headache." People like to use what they like.
- eksith 13y agoSame reason people write things in Var'aq : http://www.reocities.com/connorbd/varaq/index.html http://www.reocities.com/connorbd/varaq/index.html The more "close to the metal" you can get and more awkward and painful it is to program in, the more cred you get. Actual ramifications of slow connections, long polling etc... be damned. Come to think of it, how come we don't have a web server in Var'aq?
- weland 13y agoIt'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.
- running_foo 13y agoWhat are some frameworks for web developing in C? Is KORE also a framework or just a server? As for the server, I wonder how performance compares to say, OpenResty loading Lua compiled to bytecode.
- a-priori 13y agoOkay 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 useful for CPU-bound applications when you can assume fast clients and short requests. In fact, I could make this server grind to a halt by opening one connection per worker, issuing partial requests to each, then letting the connection hang. So to be used in production, this server will have to sit behind something like nginx, which can insulate your application from pathologically slow clients.
- codex 13y agoThreaded servers are not necessarily slower than asynchronous architectures, though they can be. In fact, threaded models are coming back into fashion these days, and can (sometimes) be faster than asynchronous models when each thread is affine to a particular physical CPU. This is due to cache effects and the substitution of fast stack allocation for slow heap allocation. Bazillions of threads using too much stack space have been a problem in the past, but these days servers have plenty of memory, and to some extent size can also be mitigated by tail call optimizations. I don't think your particular DoS attack will work with this server, which implements an idle timer to recover stack space. However, they could go one step further and only allow worker threads to use n% of server memory, and killing old, slow connections when the thread is needed and the memory limit has been reached.
- FooBarWidget 13y agoModern threading implementations are pretty good. Plus, a lot of the memory threads use is just virtual address space, not real memory. On 32-bit systems you ran into the problem of running out of virtual address space with a few hundred threads. With the popularity of 64-bit platforms this problem has gone away. Plus, because this is C, it's trivial to reduce the stack size to, say, 512 KB without too many problems.
- mpweiher 13y ago
- antihero 13y agoWould it be an interesting idea to create a framework for making webapps as nginx modules? Sure, it's a pain in the ass, but nginx is evented as opposed to thread pooled, and tried and tested. Because nginx takes up hardly any memory, you could run a single nginx instance and proxy to other nginx instances that are compiled purely to run the app. Though the scope for creating critical vulnerabilities is huge.
- FuzzyDunlop 13y agoThat sounds like OpenResty: http://openresty.org http://openresty.org
- eric_bullington 13y agoThere is such a framework: openresty http://openresty.org/ 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.
- fcambus 13y agoLapis is also worth mentioning : http://leafo.net/lapis/ 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.
- antihero 13y agoThat looks really interesting, thanks.
- readme 13y agoTrying that out now myself. It's OK but has a long way to go if it is to compete with the current platforms dujour.
- richo 13y ago> Secure by default > SPDY Choose one, SPDY mandates gzip, and gzip in SSL/TLS is vulnerable to leaking repeated plaintext, eg cookies in nearly every implementation. http://en.wikipedia.org/wiki/CRIME_(security_exploit) http://en.wikipedia.org/wiki/CRIME_(security_exploit)
- osth 13y agoI choose HTTP/1.1 pipelining. Uncompressed headers are useful. Ordered records are returned (unlike SPDY), where "HTTP/1.1 200 OK" is the record separator. Been using this for a decade. Can't see the benefit of SPDY. Anyway pipelining is only useful where numerous resources are coming from the same host. But the way the www has evolved, so much (unneeded) crap gets served from ad servers and CDN's. Pipelining isn't going to speed that up. HTTP/1.1 pipelining was never broken. It was usually just turned off (e.g. in Firefox), while most web servers have their max keep alive set around 100. In plain English, what does that mean? It means "Dear User, You have permission to download 100 files at a time from http://stupidwebsite.com http://stupidwebsite.com. That is you can make one request for 100 files, instead of 100 separate requests, each for a single file." And what do Firefox and other braindead web browsers do? They make a separate request for each file. But heay, never mind all those numerous connections to ad servers to retrieve marketing garbage (i.e. not the content you are after), lets concentrate on compressing HTTP headers instead. Brilliant. It's trivial to use pipelining: 1. Feed your HTTP requests through netcat or some equivalent to retrieve the files and save them to a concatenated file, 2. split the concatenated file into separate files if desired, 3. view in your favorite browser. No ad server BS. Now that's "SPEEDY".
- dcsommer 13y agoPipelining 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.
- osth 13y agoI 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 line blocking or lack of header compression. I think users just were not clued in about pipelining. The speed up between not using pipelining and using it is, IME, enormous. 1 connection for 100 files versus 100 connections for 100 files. It is a huge efficiency gain. Yet most users have never even heard of HTTP pipelining, or never tried it. If they really wanted such a big speed up, why wouldn't they use pipelining, or at least try it? Why wouldn't they demand that browsers implement it and turn it on by default? Users are being encouraged to jump right into SPDY, a very recent and relatively untested internal project (e.g. see the CRIME incident) of one company, most users, if not all, having never previously experimented with even basic pipelining, which has been around since the 1999 HTTP/1.1 spec and has support via keep alives in almost all web servers. Noticeable speed gains would be seen if www pages were not so burdened with links to resources on external hosts. That's what's really slowing things down, as browsers make dozens of connections just to load a single page with little content. The speed gains from cutting out all that third party host cruft would make any speed gains from avoiding theoretical potential head of line blocking during pipelining seem miniscule and hardly worth all the effort. If you want to see how much pipelining speeds up getting many files from the same host, you do not need SPDY to do that. Web servers already have the support you need to do HTTP/1.1 pipelining. (Though on rare occasions site admins have keep-alives disabled, like HN for example. In effect these admins are saying, "Sorry, no pipelining for you.")
- aray 13y agoWhy the ISC license? The site just says "Kore is licensed under the ISC license allowing it to be used in both free and commercial products." but don't Apache 2, BSD, and MIT all satisfy this as well. IANAL, but here's a quick summary of ISC vs MIT: http://www.tldrlegal.com/compare?a=MIT+License&b=ISC+License http://www.tldrlegal.com/compare?a=MIT+License&b=ISC+License
- ams6110 13y agoWeb development in C. Reminds me of aolserver. http://www.aolserver.com/docs/devel/c/ http://www.aolserver.com/docs/devel/c/
- dschiptsov 13y agoCeased 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).