httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Mitschke <robert.mitsc...@ebeesmarttechnologies.de>
Subject Re: Protocol converter module
Date Tue, 05 Jun 2012 11:47:32 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message