FastCGI connector

[indeyets]

We need a FastCGI connector. FastCGI support is more widely available than SCGI support and protocol is more capable in general (multiplexing support).

The plan is to implement FastCGI connector using php's fastcgi library (fastcgi library -> pecl/fastcgi -> fastcgi connector)

[indeyets]

moved uploads-related request to: https://github.com/indeyets/appserver-in-php/issues/issue/7

[PAStheLoD]

First of all, thanks for the fast reply! And regarding backend servers, what's your opinion on assigning a separate port to each worker, just as Thin does for Ruby on Rails?

[indeyets]

I recommended "separate port" approach when "aip" tool was still not implemented. some clients still do that, but it doesn't make much sense anymore.

aip-tool does forking and lets you have as many workers on single port as needed

p.s. I really should setup mailing-list/forum for AiP ;)

[PAStheLoD]

It might be a good idea, indeed. :]

I've asked about the one port for one worker approach, because I've just took a glance at strace of a worker, and it does a lot of syscalls which I've hastly attributed to locking/passing around the socket, and thought isolating them wouldn't be a bad idea. (Then, after looking at the aip-tool's trace, I felt rather dumb, because that just sits there in a wait4. So I have no idea how exactly that part of request handling works, and I had no time to look delve into the source.)

[indeyets]

there isn't any explicit locking/passing of socket. the only possibility is, that php does something implicitly. but I doubt that.

so, those syscalls are related to something else

I have started to implement this, but ran into a small problem. Allthough there is no abstract class or interface to explicitely force this, AiP expects protocol classes to implement the getStdin function to return a valid open file pointer.

The problem is, that any protocol, that needs decoding, can't provide a valid file descriptor unless it writes the stdin contents into a file or internal socket. Also, the HTTP parser doesn't correctly implement RFC 2616, because it doesn't, and in fact can't support any transfer encoding except for binary. The application may work around this limitation, but the HTTP layer should handle this transparently.

Update: I suppose, I could write a stream wrapper for this, but that's an ugly hack and I can only hope, that noone tries to run socket functions on it.

[indeyets]

@JasonZen in PHP there isn't such thing as "file descriptor", but there are streams instead. And stream handlers can be implemented in "userspace". check https://github.com/indeyets/appserver-in-php/tree/master/AiP/Common for example.

p.s. just noticed "update". why do you consider this to be ugly hack?

[indeyets]

Regarding "HTTP parser". You can use pear.indeyets.pp.ru/httpparser php extension, if you need to handle more of HTTP. But, fixes for php-based parser are welcome :)

Also, consider, that putting AiP in front of end-users is not considered a good idea. It's better to cover it with some real http server, such as mongrel2 or nginx. they will handle complex http and will use simple protocol to interact with AiP

I'm considering writing a stream wrapper an ugly hack, because it's not explicitly documented, that getStdin() returns a stream, not a socket, so someone may be tempted to run socket functions on it, which won't work, if it's a stream. From the API standpoint I either see a lack of documentation or a lack of properly defined interfaces.

For now I will go with the stream implementation as much as I don't like it. If it works fine, can I file a pull request?

[indeyets]

I agree. this is the documentation problem

pull requests are welcome, sure. pear coding style is preferred