[FASTCGI] Shouldn't Multiplexing be deprecated?

Artyom artyomtnk at yahoo.com
Mon Nov 15 02:23:41 EST 2010

Hello All,

Current FastCGI specification define Multiplexing of several connections
over the single socket.

There are actually two problems with this:

1. There is no way no make blocking notification to FastCGI
   server in writing long response
2. No web server I aware of and almost no client library implement

1st problem:

Let's assume I have two clients requested for download two different 1GB files 
FastCGI backend. Client #1 has 2.5 MB/s connection and other has slow 56KB/s 

The first client would be able to download the file in about an hour while for 
other it would
take about day and a half.

However fastcgi server is not aware of the connection speed and would likely to 
push both
responses in same speed. So the web server has two options:

a) either disconnect slow client
b) cache entire 1G response until the client completes download in 1.5 day.

Now if the web server has two distinct non-multiplexing connections it could
just not read the data from one of connections till the client consume its data 
and allow the fastcgi server to block on the connection or put it into
select loop write-ability test.

2nd problem:

Following web servers (I've checked) **do not** implement multiplexing:

1. Apache mod_fastcgi (official fastcgi package!)
2. Apache mod_fcgi (alternative fastcgi module)
2. Lighttpd
3. Nginx
4. Cherooke
5. IIS FastCGI module (from what I read, didn't check the code by myself as it 
is not available)

Following client libraries (I've checked) **do not** implement 

1. libfcgi - the official fastcgi libary
2. PHP - not implements
3. Then I stop checking...

So generally all popular production quality web servers that use FastCGI today
do not implement multiplexing.

Shouldn't multiplexing be deprecated?



More information about the FastCGI-developers mailing list