NEWS  : I am pleased to announce that mod_cgisock has reached beta testing stage . The current version is 0.1.0 and should be reasonably stable as well as easier to use . It has been tested for GET and PUT methods along with better sanity checking . Note that this version also has some changes to its configuration tokens . Please refer to the NOTES and CHANGES files included with cgisock for further details .

This is still a work in progress , however in response to questions asked about
cgisock , I hope that this document may shed some light on the more frequently
asked question .

Question List :

1) What is cgisock ?
2) What is the mod_cgisock protocol ?
3) Why did you write mod_cgisock ?
4) Have you seen FastCGI and dont you think youre re-inventing the wheel ?
5) Are there any unresolved issues with cgisock ?
6) cgisock doesnt seem to work with Win 95/98/NT . Whats wrong ?
7) Where can I get cgisock ?
8) Can I use script language X with cgisock ?
9) Who are you anyway and what do you do and who do you work for ?

1) What is cgisock ?

The short answer to this question is
' mod_cgisock is a socket based implementation of the Common gateway interface '

The long answer is cgisock is a module for the Apache web server which allows a method
by which apache can serve up a CGI script or program via a unix domain socket instead of
loading the program into apache's memory space . It probably best described as an
experinment  to determine the feasability of serving up a socket in this manner . However
some of the features not evident at first glance include -

    1) Complete independence of cgi script process model with the CGI server programmer
having the option to write in just about any language and process style . A script can
share information between URL's  as needed .

    2) Apache uses the socket to communicate with the script . Therefore , absolutely
any language can be used at the other end that can handle sockets.

    3) Saves space in the server children and with a well writen cgi script to match , should
be able to service http requests _much_ faster than existing methods with far less memory
overhead .

    4) Allows for independent script restarts that can be hot swapped on an active
server . Independent Apache reconfiguration on the fly with no need to restart the
cgi socket scripts .

    5) Dynamic socket creation by scripts is possible with sockets required being
created in a socket directory ( No extra reconfiguration necesary aside from
declaring the directory in the apache configs ) . Cgi scripts can handle one or
multiple sockets as needed ( even alternate handling of a socket by serveral scripts
if youre into that sort of thing - not recomended though !)

    6) It should run quite happily along side mod_cgi . Its not intended to 'hijack' the cgi
interface in any way . So mixing cgisock with other cgi modules should be no problem .

    Along with the distribution , there is a small perl script called test_harness to demonstrate
the function of cgisock . Note that this script must be run as root OR you place the socket it
creates into an area that the script has permission to use . If you follow the instructions for
including cgisock into your apache build ( NOTE : this was built using apache 1.3.4 . I havent
tried it with other versions yet so your milage may vary ;-) then run the script you should get
a small page that has been programmed into it .

    Important Note :
The current  version contains methods by
which sockets can be safely served without comprimising the stability of Apache . Versions earlier than V 0.1.0 should be upgraded to 0.1.0 since this is the beta version and should be stable enough to even test out on the odd production site . Version 0.1.0 also does more sanity checking.

2) What is the mod_cgisock protocol -

    Refer to the NOTES file included with cgisock for a discussion on using the
cgisock protocol .

3) Why did you write 'mod_cgisock '

    I wrote this becuase it was related to a multi-threaded server program I am writing .
I looked at cgisock and thought  that other people might get some benefit from it so I
released it for  public use  .

4) Have you seen 'fastcgi' and dont you think youre re-inventing the wheel ?

 No not really . Its hard to compare FastCGI as it includes an API with its
function and can do a lot of the work for you . Cgisock is more comparable to
PCGI except that instead of using a persistent CGI process to interface
with apache , its like having PCGI built into Apache so that there is no
requirement for the intermediate process . Thus Cgisock cuts out the
middle man and yields better performance through the fact that your data
passes through less processes before it gets to the client . Cgisock also
gleans a little more performance than FastCGI since it does not have to
manage your CGI processes for you and as such does less work . I note
here that FastCGI has to do a certain ammount of  header parsing and
decision making in manging which CGI gets what data . Cgisock does
not involve itself in these decisions by utilizing the per directory configs
and as such gains some performance improvement by simply translating the
destination of the request as per your pre defined configuration . Also ,you
can start you CGI servers independently of an Apache server built with
Cgisock  . Cgisock will happily bounce  requests until your CGI server
is started ( and bounce them if it should crash ) .

However most of all , if you want to use mod_cgisock , be prepared to get
your hands dirty .....

5) Are there any unresolved issues with cgisock ?

    Not as many as there were .  This module should work straight out
of the box with minimum hassle . Many of the earlier issues have been
resolved and cgisock should be quite well behaved now . Note that there
is still issues involved with the error message that Cgisock can yield .
Unfortunately I havent got this module to the stage where it will
produce HTTP 1.1 spec errors as they were meant . So until I have sorted this
point out , If something should go wrong , the resultant error messages
my be a bit confusing until I get this sorted out . In all honesty , I dont
think the HTTP protocol is quite ready for cgisock yet , however , it still
works and should do the job in spite of this point .

    The beta release is currently available ...

6) Cgisock doesnt seem to work with Win 95/98/NT , Whats wrong ?

    Well , you see its like this , when it comes to MSWin programming ,
I sort of avoid like the plague . In all honesty I am not really aware if
Win does unix domain sockets . You see , the socket is located in
the unix directory tree and uses special file system flags to tell the
system its a socket . Im not sure if such facilities exist at all in Win .
If someone has further information on this or wants to port cgisock
to windows , then you are quite welcome to . However at this stage , no
cgisock does not work under windows and there are no plans at this
stage to port it to windows .

7) Where can I get mod_cgisock ?


8) Can I use script language X with mod_cgisock ?

This depends on how your language deals with memory usage . If you have a degree
of control on what and when memory is allocated by your language , then yes you
should be able to use it quite successfully . A note though said language must be
able to use unix domain sockets . Note that this does NOT include Java and tcl .
Java and tcl were both designed to be cross platform compatible and since some
systems dont implement unix domain sockets , these must forego this function as
well ( although I have heard rumblings about sockets in Java ). However at the time
of writing , Perl , python , C++ and C are all known to work , many others should too.

A NOTE TO PERL USERS : Because of the fact that your script is
persisting, make sure you use local variables in your script ('my ($a,
$b)', 'local ($a, $b)'), wherever possible and undef the big ones once
you do not need them anymore ('undef $a'). Otherwise you will see the
memory footprint of Perl growing beyond limits.

Many thanks to Nick Hibma for this pearl ;-) .

9) Who are you , what do you do and who do you work for ?

    I am a  computer technician from Kempsey , on the mid-north coast of N.S.W,
Australia . I usually do electronic repairs and the odd bit of machine work for my
father . My company , Castle Industries , is still getting up to speed ( even though
its been in existence for nearly as long as I have ) however after nightmare upon
nightmare trying to get MS software up and going correctly , I have since given
up trying and deal exclusively in Linux based systems . For me ( and my customers )
reliability is the only key factor in system deployment and if a particular company
cannot get its act together on the reliability issue , then using the software ends
up costing more time  instead of saving it . I support linux and and the Open Source
movement because they produce software that is strong , efficient , very flexible
but most of all that is reliable . In short if you cant count on your machine to go
when you really need it , then there is no point in using it at all . Linux goes when
you really need it , so I use , support and encourage the use of linux and all Open
Source software . Put quite simply its the best money cant buy ....

Cheers Mik Voase.