From my understanding as soon as you call FCGI_Accept() after processing your request the server closes the connection with the client and it becomes impossible to send anything else to that client. Thus I’m wondering if there is any way to prevent that and “save” the connection (handle?) so that I can respond to the request after processing another request. I’m planning to use mod_fastcgi on Apache, if it makes a difference.
The story:
I’m trying to make an instant messaging system using FastCGI on the server and Ajax long-polling on the client side. The idea is to make an event-driven server where a client’s “get” request checks for outstanding message to return or have the connection stored for later response; and a “send” request checks for an available connection to the recipient or store the message in memory if unavailable. The only reason I’m using FastCGI in the first place is because as it uses a persistent process it allowed resource sharing between connection, so I’m open for other suggestions. I am aware that you can use a database as a shared resource and have each connection spawn a process that polls the database for new information, and although it works it seems terribly inefficient. The only other alternative I can think of at the moment (if FastCGI cannot accomplish what I need) is to create a custom Apache module that implements the above, but that’ll probably be more trouble then it’s worth.
I’ve just started researching into FastCGI so perhaps this is not the most appropriate solution to my problem, but this is the first obstacle I ran into. Thanks in advance.
What your are describing have nothing todo with FastCGI. It’s the way connection less architecture HTTP is working. Long polling sesstions have to be hold be by the client (and server in the best case). Continue reading at http://xmpp.org/extensions/xep-0206.html
A more advanced but new technology is http://www.websocket.org/