Re: Plumbing of Fast CGI Streams

Mark Brown (mbrown@OpenMarket.com)
Thu, 04 Jul 1996 10:54:15 -0400

Message-Id: <199607041454.KAA25272@breckenridge.openmarket.com>
To: Jim Fulton <jim.fulton@digicool.com>
Subject: Re: Plumbing of Fast CGI Streams 
In-Reply-To: Your message of "Thu, 04 Jul 1996 10:07:53 EDT."
             <31DBD039.F5A@digicool.com> 
Date: Thu, 04 Jul 1996 10:54:15 -0400
From: Mark Brown <mbrown@OpenMarket.com>


Excellent questions.

    > But if the buffer fills the
    > application will block.  In the future we'd like to make the buffers
    > expand on demand in order to prevent the application from blocking on
    > output.

    I think that this is pretty critical, epecially if you aim to support
    state-full single-threaded applications.

Can you explain what you mean by a state-full application?

I agree this is an important issue, but it seems important to
*any* application that writes more than the server is prepared to
buffer.

    We develop state-full applications and splitting these applications
    into multiple processes is unattractive.  We can't, in general, limit
    the amount of data these applications input or output, so if we want to
    use Fast CGI, it appears we need a multi-threaded library.

Can you explain why you can't use session affinity to run your app
as multiple processes?  In many cases session affinity works well.

    OK, suppose we decide to write a multi-threaded Fast CGI
    application library.

    Now, we seem to have three choices:

    - Accept multiple requests over a single multiplexed connection,
    - Accept multiple requests over multiple non-multiplexed connections, or
    - Accept multiple requests over multiple multiplexed connections.

None of the *servers* supports connection multiplexing today,
so your second option is the way to go today.

As you point out, the server must implement very flexible buffering
to make connection multiplexing work.  That's one reason why
the Open Market server doesn't perform connection multiplexing today.
Multiplexing doesn't make sense for Apache and NCSA, which handle
only one request at a time per server process.

We provided for connection multiplexing in the protocol from
the outset because as performance standards rise (and they are rising
quite steeply) multiplexing is bound to become necessary.

    --mark