Dear Sorin, again thanks for your valuable response. The architecture is now clearing up in my head which makes me a happier man after days of reading Apache code (which in turn is a valuable and interesting exercise by itself).
>> Doing >> it as a protocol handler I guess does work. In the protocol handler I >> could >> then still call the hook for processing a http request that I am creating >> based on my proprietary protocol right? >> > > When you say "process a http request" that you create you mean process its > response, don't you? Yes, you can get the response. For my SMPP module I > did with mod_proxy but I suppose you can do it with any http client lib. No, what I would like to do is write an adapter from my binary tcp bidirectional protocol and derive xml based http requests from it so that I can process them using standard application server infrastructure. Therefore, whenever I receive a message from my client, I would want to create a request_rec on my own and send that up for handling. When the application server wants to send me something to send to the client it can either put that into a response of a request that I sent, or it can send me a http request that is not related to a message from the client. Therefore, when I receive a message from my client in the protocol handler I would like to still be able to create an (fake) http request and have that handled as a normal http request. Ideally I would like to maintain the ability of reverse proxying so that the request does not need to be handled in my apache instance locally but could by forwarded to any other server of my choice. For the messages that the application server wants to send me outside of normal http responses I would of course need to create a handler that would then handle the request by notifying the protocol handler using the pipes as suggested by you. > > > I have also thought about the shared memory approach to communicate >> between >> the individual children. How would I go about listening on input from >> shared memory without doing a polling approach? >> > > You could open a pipe in post_config (i.e. before the parent forks its > worker children). The pipe descriptors are then inherited by all children. > In process_connection you perform a timed select on two descriptors: the > socket from the non-http client and the reading end of the pipe. When you > get a triggering third-party http request, in your http handler you write > something to the shared memory to the writing end of the pipe. This wakes > up one of the non-http handlers which can check if the triggering request > was for the client it handles and then it can proceed with pushing on the > non-http socket. > > How do I go about implementing this select. I have searched through the code but could not find out a way to actually get a handle to the socket. In the code all that is handled are network buckets. How would I gain access to the socket handle in process_connection? I would need that handle to select on it. It is great that I will not even need to use a separate thread, this way the architecture is much cleaner now. Best regards, Robert
