httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sorin Manolache <>
Subject Re: Protocol converter module
Date Tue, 05 Jun 2012 15:53:30 GMT
On 2012-06-05 13:47, Robert Mitschke wrote:
> 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).

I see a problem with the "select" approach.

When the handler writes to the pipe, in order to wake up some thread, it 
has no control of which thread wakes up.

So if the wrong thread wakes up, it will check the shared memory, it 
will not find its ID there and it will do nothing. On the other hand, 
the right thread keeps sleeping so it has no chance to see that its ID 
showed up in the shared memory.

So I think it is better if the threads wait on a condition variable and 
they are woken up via a notify_all. However, I have no idea how you can 
combine waiting on the condition variable _and_ on client data on the 

Ideally a thread should sleep if (1) no activity is detected on the 
socket _and_ (2) it is not told by an external request to push data to 
the client.

I think I could have mislead you along a wrong path. I'm sorry.


>>> 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

View raw message