[FASTCGI] fastcgiapp socket creation
rclemley at booksys.com
Fri Oct 15 19:03:57 EDT 2010
I'm not sure about lighttpd, we use apache2.
The call to FCGX_Accept() as in echo.c, without initializing the socket
causes FCGX_Accept() to listen on file descriptor 0 (standard input).
(You can see that this is how the lighttpd example "C/C++ FastCGI on
lightty named socket" also uses socket file descriptor 0.
In both Apache2 and lighttpd you can configure the fastcgi server to be
internal (started by the webserver) or external (started independently
of the webserver). I recommend running external FastCGI servers (some
of the reasons are clearly outlined on the lighttpd fastcgi doc). In
this case, you arrange for your fastcgi server to be configured and
started independently of the web server, using /etc/init.d scripts,
daemontools, spawn-fcgi, etc.
In the external FastCGI server scenario, our server follows this general
FCGX_Init() -- no parameters
socket = FCGX_OpenSocket(socket_string) // careful about file
running = True
Loop while running is True:
FCGX_InitRequest(&request, socket, FCGI_FAIL_ACCEPT_ON_INTR)
Loop while running is True and while nothing on socket:
retval = select(socket+1, ...) // timeout of about 1
second plus or minus
Check for interrupts, server stop signals, etc.
If server needs to stop, Then set running = False
If running is True:
If successful accept, spawn a thread to handle and deallocate
Else deallocate the request.
The interesting thing about FCGX_OpenSocket() is that it can take a port
number (as a string) or a Unix Domain Socket filename. In this way, you
should be able to write this part of your server to work as either an
internal or external FastCGI server. You will need to pass parameters
(such as the Unix Domain Socket filename, the NT Named Pipe, or a port
number) to your server either through the environment or on the command
line or read from a config file. The other thing about
FCGX_OpenSocket(), is that you need to be careful that the file it
creates will have the correct permissions to allow your webserver (your
client) to connect to your fastcgi server.
You should also arrange for your server to shut down cleanly in the
event of a signal or other method of notification (the "select()" loop
helps with that).
I can see that lighttpd has a configuration variable "socket_dir" which
could come in to play here.
When using FastCGI library, the source code is often the best documentation.
FYI: It's not *my* website :-)
Hope this helps,
On 10/15/2010 04:22 AM, baerni at bluewin.ch wrote:
> I am writing a web app in C, using lighttpd and the fcgiapp library. A first sample is working now, based on the
> echo2.c examle.
> Since I had some troubles to make the setup work, I would like to ask some questions get a better
> understanding of seting up and
> starting a fastCGI application with lighttpd (mod_fcgi):
> 1. On your website I found a
> link poining to a manual on the lighttpd page. It contains a configuration and c program example.
> The c program is
> using the funtion FCGX_Accept_r. When I started the lighttd server I figured out that the server starts the
> application as many times as the number of processes configured in the lighttpd config file and creates a socket for
> each process, ending with -0 ... -n. Unfortunately the sample c program does not create any socket and therefore does
> listen to anything. I was able to make it work with a one process configuration and creation of a hard coded
> socket with
> the same name as the one of the lighttpd server (test.fcgi.socket-0). Since the lighttpd server does not
> pass any arguments
> to the fcgi application about socket locations and names, I wonder how this must be set up to
> work properly.
> 2. My current setup is made based on the echo2.c example mentioned in the documentation of your
> development kit. Unfortunately
> the source file is not available in your development kit and I had to get it from
> somewhere else on the web. The setup was working
> without any problem. The only thing I wonder is how the application
> figures out on which socket it should listen, since it just
> waits on the accept function. I would apreciate if you
> may let me know more details about the "magic" of how the application
> knows where the socket of the webserver is,
> since the socket is created by the webserver and the fcgi application is started
> by the webserver without passing
> any arguments.
> Kind regards
> FastCGI-developers mailing list
> FastCGI-developers at mailman.fastcgi.com
More information about the FastCGI-developers