It's ironic that the website isn't working. Alternate link? (GitHub perhaps?)
KORE – A fast SPDY-capable webserver for web development in C
11–20 of 60 posts
Re: KORE – A fast SPDY-capable webserver for web development in C
#12Why web development in C? Seems like a headache.
People like to use what they like.
Re: KORE – A fast SPDY-capable webserver for web development in C
#13As 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.
Re: KORE – A fast SPDY-capable webserver for web development in C
#14Connection timeout? Brilliant idea, I especially love the SSL only. The web needs to move to pure SSL.
Re: KORE – A fast SPDY-capable webserver for web development in C
#15Though the scope for creating critical vulnerabilities is huge.
Re: KORE – A fast SPDY-capable webserver for web development in C
#16Would 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 .
Re: KORE – A fast SPDY-capable webserver for web development in C
#17Web development in C, I love this.
Edit: This is web development in C: https://github.com/jorisvink/kore_website/blob/master/src/si...
Re: KORE – A fast SPDY-capable webserver for web development in C
#18Okay 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…
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.
Re: KORE – A fast SPDY-capable webserver for web development in C
#19Why web development in C? Seems like a headache.
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?
Re: KORE – A fast SPDY-capable webserver for web development in C
#20Would 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 .
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.