Hi Artyom, On 20 May 2010 08:04, Artyom <artyomtnk@yahoo.com> wrote:
- Unix domain sockets - MUST
As noted in the docs, this is a future goal. What makes them such a necessity?
Because they are much more efficient then TCP/IP onces, so if you deploy application on Unix you will want to use them.
I'm going to add this support soon so I can take some performance metrics. I'd be suprised if the performance difference was huge, as TCP sockets are pretty efficient these days. They also have several other advantages like not colliding with other
application when listening on same port accidentally.
IIUC mod_fcgid will only try to use a free port and carry on regardless if if finds one in its working range which is in use. The library will simply use the port (or ports) assigned to it unless you explicitly bind to a particular port. I've considered adding support to the library for accepting on a range of ports but it slipped my mind! Boost.Range might be fit for this purpose, so I'll get back on it.
As I see it, recompiling just to use Unix sockets instead of TCP is unacceptable,
I agree that there is no reason to do this for FastCGI and CGI (even official libfcgi supports it) but if you once implement SCGI you will want to be able to switch between FCGI/SCGI without recompilation.
I don't think there's any foolproof way of doing this interrogation automatically? If it's a manual, runtime configuration option anyway, then the library user would be able to use the sort of selecting I mentioned in my previous post. Again, there is non-trivial overhead in supporting both SCGI and FastCGI under-the-hood so library users shouldn't have to pay for this unless they want it.
Indeed. I started support for SCGI in the past but have removed those parts for now since they aren't complete. Adding support is just a matter of fnding the time as the design of the library should support an implementation.
I fully understand this, I just suggested, not SCGI protocol is so simple that it can be implemented in several hours. (At least that what It had take for CppCMS)
Ok.
Once again, don't try to leave in illusion that support of wide character would give you any advantage in Unicode support.
Oh I'm not.
See: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html#myths
Looks interesting. You should get this to review.
Session managements I would strongly not recommend you using boost::serialization for this purpose. Performance is terrible (from my experience).
What would you suggest as an alternative?
Use key value pairs as they most popular data stored in sessions. And allow value be serializeable object for complex data structures.
Sounds like reinventing Boost.Serialization, but with fewer features. I'd rather support things that people already know & use when there is something available. FWIW, adding a SessionManager that uses Boost.Interprocess is on my TODO list.
I think supporting lexical conversion is a requirement of any CGI library,
so the as<> and pick<> data access functions are provided for this use. In the absence of better an alternative, if these two functions were documented with caveat about lexical_cast, would that be sufficient?
You can always use std::stringstream (what lexical_cast is actually uses) but you must imbue std::locale to the stream like this.
template<typename Number> Number to_number(std::string const &s) { std::stringstream ss; ss.imbue(std::locale::classic()); ss.str(s); Number r; ss >> r; if(!ss) throw .. return r; }
If library users want this they can use it like so: cgi::request req; int first_way = req.get.as<int>("some-get-variable"); int second_way = atoi(req.get["some-get-variable"].c_str()); int third_way = to_number<int>(req.get["some-get-variable"]); assert(first_way == second_way == third_way); All of the request data is available in types that are implicitly convertible to a string and have a c_str() function that returns a const char_type*. For example: cgi::request req; // You can get full access to the request data in its "native" type. cgi::form_part& data = req.uploads["some-file"]; // All "native" request data types are implicitly convertible to a string. // In the case of CGI, the string_type is std::string so this works too: std::string upload_filename = req.uploads["some-file"]; Does that give you what you need?
Indeed, I am testing with lighttpd and nginx at the moment. I have found an experimental plugin for for nginx that supports "proper" multiplexing too, which looks promising.
Few words about multiplexing:
1. There is not a single web server that implements multiplexing as it much simpler and efficient to just open another socket.
Zeus does and so does the nginx implementation I mentioned.
2. More then that the only web server I have ever seen using Keep-Alive was cherooke (and I think IIS over pipes because pipes are not sockets)
What does this mean?
3. Even official fastcgi library do not support multiplexing.
I know, but that's no reason not to support it.
4. There is always way to tell to web server if application supports multiplexing or not. (on of commands of fcgi)
Again, this is just a workaround.
5. There is deep problem with multiplexing as there is no way to tell fastcgi application that it can't send data meanwhile
For example you have two clients downloading big csv file of 1G one has connection slower in two times then other.
So if they have multiplexed connection then either both clients will revive data at the lowest speed or web server will have to store about 0.5G in its internal buffers.
So multiplexing is generally bad idea.
I've thought long and hard about this and I don't think your assertion is correct. The library doesn't support restartable form parsing right now because of the problem you're talking about. With careful design and some clear caveats for users I believe this can be made a non-issue. My suggestion - don't waste your time on it. It useless feature
that theoretically could be useful but nobody uses it.
Also fastcgi specifications allow you as library developer not to support multiplexing (actually I hadn't seen any fastcgi client that implements multiplexing).
Peter Simons' libfastcgi does support multiplexing, but isn't a complete client library, just a protocol driver. This library "potentially" supports multiplexing. There are a couple of things that need to change internally to support it but as soon as I get my hands on a server I think it's doable.
CgiCC is not compatible with the BSL so I can't use it. It
also does not support lazy loading of requests or multiplexed FastCGI, which have always been goals of this library.
As I mentioned before multiplexed FastCGI exists only on paper. Don't waste your time.
I assure you it's real, but I'm not going to defend it much until there are some performance metrics supporting it. The goal of supporting multiplexing is less about pure speed than about resources. Having 1 connection per request means you can only support N simultaneous requests, where N is not really that huge of a number on most machines. Cheers, Darren