Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of pon.umapathy@gmail.com
 designates 209.85.217.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAHD+r2=fFeGi1fa5kgzAwzcxycgkQj40iacZYPnstsH_poJZ8g@mail.gmail.com>
References: 
 <CAEqv1uD1x_4hg6tC5PaoUDQRZO0EGksk_=J==_nPQGdTGe_TAg@mail.gmail.com>
	<CAHD+r2nZC+W5Lz=rxkkF42dRdAzsxwzg9Bv1zv9jAjuQgtUKFw@mail.gmail.com>
	<CAEqv1uAmscxpazrVMKE0a3WRTpPXzbyknAoiGDS3RKUnCnWCaQ@mail.gmail.com>
	<CAHD+r2=fFeGi1fa5kgzAwzcxycgkQj40iacZYPnstsH_poJZ8g@mail.gmail.com>
Date: Fri, 27 Sep 2013 15:04:26 +0530
Message-ID: 
 <CAEqv1uCH5aOLuoxO3SeDaPp=u7RTq96gWBgnU3wVgSR0ZSd4hw@mail.gmail.com>
Subject: Re: response handling inside ap_hook_create_request cb function
From: Pon Umapathy Kailash S <pon.umapathy@gmail.com>
To: Robert Mitschke <robert.mitschke@ebeesmarttechnologies.de>
Cc: modules-dev@httpd.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Thanks a lot, Robert.

This gives me something to work on/experiment for now. I'll probably
get back later with more questions, if needed. :)

Regards,
Umapathy

On Fri, Sep 27, 2013 at 2:57 PM, Robert Mitschke
<robert.mitschke@ebeesmarttechnologies.de> wrote:
> I am using input filters to convert the binary input messages to http. This
> is done using connection level filters. By that approach I can use all of
> the remaining apache infrastructure after the input filters. For example I
> can use mod_proxy to forward requests from my clients once they are
> converted from binary to http for handling in an application server
> somewhere else.
>
> I still needed to implement my own connection handler as I need to inject
> messages that are not originated from the client but from some other source
> into the existing connection. I did not yet figure out any other way to do
> this. Therefore I am using a single thread to handle each connection. Since
> these threads basically listen on the connection socket and the internal
> pipe I am using they are not hogging CPU but memory which for now I can live
> with.
>
> I definitely would be interested in modifying this at some later point so
> that the connection is cached in a list without a thread being exclusively
> assigned to it. But since I have to listen to the connection socket and what
> I call my "inject-pipe" I was not able to figure out a clever way to do that
> based on the event mpm. That is why I pushed this out for later.
>
> Best regards,
> Robert
>
>
> 2013/9/27 Pon Umapathy Kailash S <pon.umapathy@gmail.com>
>>
>> Thanks for your response, Robert.
>>
>> This sounds workable(with some modifications for my use-case). Can you
>> please clarify regarding a few of these points?
>>
>> "These are converted to HTTP and then passed on, the HTTP response is
>> converted to the binary format and sent back."
>>
>>  - To convert from the binary format to HTTP, input filters were used.
>> Is this correct?
>>  - How is the response conversion handled? Does this use a hook function
>> cb?
>>
>> Regards,
>> Umapathy
>>
>>
>> On Fri, Sep 27, 2013 at 1:03 PM, Robert Mitschke
>> <robert.mitschke@ebeesmarttechnologies.de> wrote:
>> > Hey Pon,
>> >
>> > I created something similar to what you have in mind by creating a
>> > connection handler. My goal was to create a bidirectional protocol for
>> > charge points for electric vehicles. I have requests coming from charge
>> > points that are in binary format. These are converted to HTTP and then
>> > passed on, the HTTP response is converted to the binary format and sent
>> > back. In addition requests coming from the backend system to the charge
>> > point arrive at the apache, are converted to binary format and then
>> > injected
>> > into the existing connection.
>> >
>> > I did this by implementing filters to convert the binary format to HTTP
>> > and
>> > by creating a connection handler that listens for incoming data from the
>> > charge point as well as for requests that are coming in from the backend
>> > systems. These are handled in separate request handlers which then
>> > communication with the connection handler internally via pipes.
>> >
>> > The connection handler is the entity that then decides on whether an
>> > when
>> > connections are closed or kept alive.
>> >
>> > Best regards,
>> > Robert
>> >
>> >
>> > 2013/9/27 Pon Umapathy Kailash S <pon.umapathy@gmail.com>
>> >>
>> >> Hi,
>> >> Here is a quick background on what I am trying to do(basically adding
>> >> support for websockets - in a slightly customised manner as needed for
>> >> my app):
>> >>
>> >> - Handle the initial handshake inside a cb function registered as a
>> >> handler hook(from here, I compute checksums required and return the
>> >> response headers as needed).
>> >>  Also, the socket from which the request was read is stored in a cache.
>> >>
>> >> - For subsequent message reception(on the same connection), i have a
>> >> function cb registered using ap_hook_create_request(since this is a
>> >> different protocol format message). Here, I read and parse the
>> >> messages/requests which are coming in from the cached list of
>> >> sockets(this is working).
>> >>
>> >> However, once I return from this cb, the connection/socket seems to be
>> >> closed. I guess the request is further passed down to hooks down the
>> >> line and the connection is closed since the req format is not known.
>> >>
>> >> What would be the best way to handle this scenario?
>> >>
>> >> I have the following in mind:
>> >>   - let the request not be processed any further(and keep the
>> >> connection
>> >> on).
>> >>   - create a req structure with dummy http headers that i can later
>> >> recognise and handle inside my handler hook to just ignore later on
>> >>
>> >> are there any examples/notes on how these can be achieved?
>> >>
>> >> Regards,
>> >> Umapathy
>> >
>> >
>> >
>> >
>> > --
>> > Robert Mitschke
>> > CTO
>> > Ebee Smart Technologies GmbH
>> > Torgauer Str. 12-15
>> > 10829 Berlin
>> > Germany
>> >
>> > m: +49 179 5442756
>> > p:  +49 30 609837111
>> > w: www.ebeesmarttechnologies.de
>> > e: robert.mitschke@ebeesmarttechnologies.de
>
>
>
>
> --
> Robert Mitschke
> CTO
> Ebee Smart Technologies GmbH
> Torgauer Str. 12-15
> 10829 Berlin
> Germany
>
> m: +49 179 5442756
> p:  +49 30 609837111
> w: www.ebeesmarttechnologies.de
> e: robert.mitschke@ebeesmarttechnologies.de