[udp]

Hmm, looks nice :-)

At a glance, I'd say it looks both more lightweight and more high-level than Lacewing (Lacewing won't host anything at all unless you add in a handler which calls SendFile or whatever, whereas Mongoose seems to have a concept of a document root and things like that).

Mongoose seems to use select() and nothing else (I only had a quick read through the source, mind), whereas Lacewing opts for things like epoll/kqueue/IOCP, which should mean that Lacewing might scale better to many clients.

Mongoose also appears to use multithreading, which Lacewing currently avoids in favour of the reactor-esque Lacewing::EventPump. Lacewing has, however, been designed with multithreading in mind, and it's something I'll be adding as an option for the Server and Webserver classes in the near future.

By the way - Lacewing does provide a C API too, despite being written in C++.

[tptacek]

Mongoose is only selecting for the listening socket, so the comparison there isn't particularly valid. Mongoose scales as well as threads on its platform scale.

Mongoose also does a fair bit more than your software does, including SSL, CGI, HTTP Authorization, and file uploads.

Neither of them, frankly, are particularly trustworthy in their present state (Mongoose has apparently actually been audited by someone, but it too stores lengths in signed u64s). But Mongoose, for all its extra functionality, is actually somewhat smaller than yours.

I'm glad you're playing with this and wish you the best of luck, and would only urge caution about advocating that people adopt this code (or Mongoose). Most developers would almost always be better off with a better tested server, or one implemented entirely in a high-level language.

[udp]

Hey, mine does SSL and file uploads. ;-)

The advice about developers being better off with a better tested server is very true, though, of course. I hope Lacewing might fit into that category one day, too.

[personalcompute]

Sorry for my ignorance, but could somebody point me to a more mature well-tested C++ webserver, as mentioned?

[udoprog]

I honestly believe that you should avoid multithread support and instead focus on the current single threaded reactor pattern. Any developer found easily just attach something like a zmq ipc queue in order to support multithreaded handling, given that the request object is thread safe. This approach would just leave you with work which ensures that the protocol parser doesn't trump any I/O overhead.

This looks very cool, thank you for sharing.