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.mitsc...@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.umapa...@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.mitsc...@ebeesmarttechnologies.de
