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 18:39:29 GMT
I hads two ideas how to overcome this problem. One would be to create a
pipe for each possible concurrent connection and maintain a registry which
pipe is used by which thread in shared Memory. As pipes are not expensive I
believe it would be feasible. The external request Handler would then look
up the correct pipe and by writing to it wake up the waiting thread.

The Alternative would be to have all blocking on the Same pipe. For each
connection Handler I want to wake up I make a Note in shared mem then write
a Single Byte to the pipe causing all blocking threads to wake up. These
will Check in the shared mem whether they are meant and only if they are
will read a Byte from the pipe.

I guess the First approach is more bookkeeping and Memory but less cpu
intensive. The later is simpler, uses less Memory but more cpu overhead.

But they should work right?

Maybe I will Start with the latter and go to the First approach only once I
have a large number of concurrent connections.

Best regards,
Robert
Am 05.06.2012 17:54 schrieb "Sorin Manolache" <sorinm@gmail.com>:

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

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