Boost logo

Boost :

From: Martin Wille (mw8329_at_[hidden])
Date: 2007-08-19 17:06:47


Darren Garvey wrote:
> On 19/08/07, Martin Wille wrote:
>> Darren Garvey wrote:
>>> On 19/08/07, Martin Wille wrote:
>>> Well two protocols can't ever be used in the same program,
>> Why is that? Can't I have a thread answering fcgi requests while another
>> one answers scgi requests? Or even a single thread that can answer
>> either sort of request?
>
>
> Hmm, well the program has to bind to port 0, where connections are connected
> to.

What? Port 0?

> I have looked into this and as far as I can tell, there is no efficient
> way to differentiate between an SCGI request and a FastCGI one: it is
> possible, but you would have a noticeable overhead to do this.

A program can listen() to and accept() connections from more than one
port. Offering SCGI and FCGI over the same port would indeed not make a
lot of sense.

> The only situation I can think of where you would have a program accepting
> with both protocols is when you have a remote SCGI/FastCGI daemon handling
> requests from different HTTP servers.

It can be a single HTTP server that mounts different SCGI/FCGI server
addresses at different points in its document tree. Not a very likely
setup, of course.

Another scenario: imagine a closed-source FCGI/SCGI hybrid server. That
server can't predict whether FCGI or SCGI will be supported better on
the HTTP server that gets used by a customer.

The scenario you mentioned isn't uncommon, either. E.g. consider an
FCGI/SCGI hybrid in a DMZ. That hybrid could get accessed from an HTTP
server inside the DMZ and from another HTTP server from the intranet of
a company.

One could also imagine SCGI or FCGI being used by programs that do not
happen to be a web server. (Supporting *CGI from the other side would be
a nice addition to your library ;)

> It doesn't seem sensible to use both
> protocols from a single server, as choosing one over the other is, IIUC, a
> configuration issue. In the remote daemon case, why would you not just
> recompile the program twice, one daemon for each protocol?

E.g. because it can make sense to implement locks inside a single
application instead of using some additional IPC mechanism for them.

Regards,
m


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk