views:

53

answers:

2

Hello, I am making a PHP frontend for a backend server using a custom protocol over TCP. Due to a fairly complex handshake when establishing connections to the backend server, I would like to persist the TCP connections to the backend server. Naturally, given the inherently stateless nature of HTTP (and especially so when using mod_php under Apache), I cannot do this directly in PHP.

I was thinking of having a local "proxy server", maintaining a pool of connections to the backend server. It is important that each user of the PHP frontend maintains his/her own connection to the backend server. Now, this is not a very complex program, but due to the many pitfalls of network programming, I would rather use a robust, mature application that could do things like this.

I am thinking something along the line of the PHP application connecting to the proxy server, states "I have an ID; 123", and from then on all content to/from the server is piped directly between the PHP frontend and the backend server.

Any suggestions on elegant solutions for this?

Thanks!

A: 

Everything you need to establish and maintain low-level TCP connections and communications:

http://php.net/manual/en/book.sockets.php

For persistent connections:

http://www.php.net/manual/en/function.pfsockopen.php

stillstanding
Thanks for your answer. I am well aware of the socket functions, but the persistent connection feature of pfsockopen is inadequate. The connections are not interchangeable - they would have been authenticated to the server, so each backend connection needs to be matched with the right frontend user. Also, without claiming I have done a lot of research on the subject, I have read bad things about certain Apache MPM combined with persistent connections (not as much bad as "does not work"). It just didn't seem worthwhile to pursue this direction. Any comments?
Nils
A: 

Here's an idea, though it might not scale particularly well:

The basic idea is that you want to proxy these raw socket connections in some way where the connection to the backend system persists.

So imagine you've got a program that creates the remote connection to your back-end system, and then creates a domain socket (a fifo), in some special directory on the front-end server, and names that domain socket after the user's session_id. The this process just proxies communication between the two connections.

I'm not sure exactly how I'd design such a proxy. You could probably write a daemon in PHP that could handle it (hint: you might want to look at some of the frameworks for php daemons like nanoserv or System_Deamon) -- not likely to be very efficient -- but might work fine. If you've got an awful lot of connections, you might want to use something with threading to avoid fork()ing for every connection.

But the basic idea is that for each open connection to the backend system, there's some process that exposes a local domain socket that your front-end PHP scripts can talk to. Those front-end, web-bound, processes know which socket because it's named after the current session_id.

How and when you setup/tear-down these connections is likely very dependent on your circumstances. You need some way for the web-bound processes to request a socket (at which point the proxy daemon does the setup/handshake, opens up the local domain socket, and starts proxying), and some strategy for closing them down.

timdev
Thanks, I'll go for a daemon running PHP. Efficiency isn't very important; there are not very many users of the system, and the daemon will basically function like a cache - if the daemon is up, great, we save some time. If it's down, the frontend will simply connect directly to the server instead (at a performance cost, of course).
Nils