FastCGI architectural questions

Sonya Rikhtverchik (rikhtver@OpenMarket.com)
Thu, 14 Aug 1997 10:33:34 -0400 

Message-Id: <199708141433.KAA06053@u4-138.openmarket.com>
To: fastcgi-developers@OpenMarket.com
Subject: FastCGI architectural questions
Date: Thu, 14 Aug 1997 10:33:34 -0400
From: Sonya Rikhtverchik <rikhtver@OpenMarket.com>


Subject: FastCGI architectural questions
To: fastcgi-developers <fastcgi-developers@OpenMarket.com>
Message-Id: <E262ZWZBHAGB0*/R=BPS/R=BPSOF/R=A1/U=VERHAS/@MHS>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Posting-date: Thu, 14 Aug 1997 10:06:00 +0000 (GMT)
Importance: normal
Priority: normal
UA-content-id: E262ZWZBHAGB0
X400-MTS-identifier: [;13600141807991/631511@BPSOF]
A1-type: MAIL
Hop-count: 3

I have read FastCGI white paper, and neither I nor AltaVista could find 
the mentioned "FastCGI Protocol Specification". I honesly would have read 
it. Where is it? (this was Question#0)


Q1. In the mailing list archive I have read that a long query over a slow 
connection blocks the fcgi process. Why is it like that? Why does the Web 
server start passing fcgi data to the process while it is still on the 
line, and why there is no buffering. Of course it is speed vs. safe 
continous/nonblocked processing. But the delay casused by buffering is 
not more than the time needed to pass data from the Web server to the 
fcgi application which are usually going to be on the same machine (90% 
of installations) or on the same lan (other 9% of installations).

  Anyway: is it an implementation issue or casued by the architecture?



Q2. I would much rather be happy with a Web server and an fgci dispatcher 
server separately. As far as I could understand the Web server is 
responsible to start fcgi processes at startup, restart them if they are 
stopped. And of course Web server is responsible to send http request 
data to the fcgi process.

I would separate the roles. Web server communicates with the fcgi 
dispatcher, which is on the same machine as the web server OR runs as a 
demon on different machine or machines.

The Web server is responsible for the communication, and the fcgid 
process(es) communicate with the fastcgi processes. Now the fastcgi 
processes can be on the same machine as the fcgid, and therefore the api 
for the client can also be simpler.


Q3. As far as I can understand session affinity and authorizer scripts 
they should have been work together, session affinity supported by the 
authorizer.

Here is my opinion what an authorizer script should do:

- - Control access based on whatever it can be based on.
- - Control session asking the Web server (or the fcgi server if the 
  scripts run on a different machie) to start a new responder process or 
  telling the Web server or fcgi server which already running process to 
  use for serving the hit.

This way FastCGI applications can run in separate processes for each user 
session, but not for each hit. Authorizer scripts can do load balancing 
between fastcgi processes, and even fast cgi processes running on 
different machines. This would also lead to scalability without 
multithread cgi scripts (which can not even be done at all in Perl being 
the most popular scripting tool).

Your opinion?

Regards,
Peter

------- End of Forwarded Message