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: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: 
 <CAEqv1uAmscxpazrVMKE0a3WRTpPXzbyknAoiGDS3RKUnCnWCaQ@mail.gmail.com>
References: 
 <CAEqv1uD1x_4hg6tC5PaoUDQRZO0EGksk_=J==_nPQGdTGe_TAg@mail.gmail.com>
	<CAHD+r2nZC+W5Lz=rxkkF42dRdAzsxwzg9Bv1zv9jAjuQgtUKFw@mail.gmail.com>
	<CAEqv1uAmscxpazrVMKE0a3WRTpPXzbyknAoiGDS3RKUnCnWCaQ@mail.gmail.com>
Date: Fri, 27 Sep 2013 11:27:11 +0200
Message-ID: 
 <CAHD+r2=fFeGi1fa5kgzAwzcxycgkQj40iacZYPnstsH_poJZ8g@mail.gmail.com>
Subject: Re: response handling inside ap_hook_create_request cb function
From: Robert Mitschke <robert.mitschke@ebeesmarttechnologies.de>
To: Pon Umapathy Kailash S <pon.umapathy@gmail.com>
Cc: modules-dev@httpd.apache.org
Content-Type: multipart/alternative; boundary=047d7b86daaa59bd0b04e75a1759

--047d7b86daaa59bd0b04e75a1759
Content-Type: text/plain; charset=ISO-8859-1

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

--047d7b86daaa59bd0b04e75a1759--