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
socket.
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.
Sorin
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
