response handling inside ap_hook_create_request cb function

[Pon Umapathy Kailash S <po...@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

Re: response handling inside ap_hook_create_request cb function

[Pon Umapathy Kailash S <po...@gmail.com>]

Thanks Sorin. I'll check this up as well.

On Fri, Sep 27, 2013 at 3:10 PM, Sorin Manolache <so...@gmail.com> wrote:
> On 2013-09-27 11:11, Pon Umapathy Kailash S wrote:
>>
>> Thanks for your response, Sorin.
>>
>> My concern in this approach is that - it would require one worker
>> thread to be held up for as long as this connection is open(and this
>> might be long + the number of clients can be higher than the worker
>> threads for my use-case/platform).
>>
>> Given that the 1st handshake message is over http, i can setup the
>> connection in a handler hookup function and return a response, freeing
>> up the worker thread while keeping the connection persistent(plus save
>> the socket/ssl in a cache shared the worker threads).
>
>
> Anyway in "normal" apache, i.e. over http, the worker threads are not freed
> up after processing a request. An idle worker thread is assigned to a
> connection when one is opened by a client for the whole duration of the
> connection. You can check that in
> modules/http/http_core.c:ap_process_http_sync_connection. You'll see that
> ap_process_request is called in a loop. The loop is left when the connection
> is closed. If the connection is idle, the worker thread is in "KeepAlive"
> state. You can check this when looking at /server-status.
>
> So it would not make any difference if you assigned a worker to the
> connection in process_connection.
>
> You'll have to take care though not to overuse the connection memory pool
> because the pool is not destroyed while the connection is open, and this
> could be a long time.
>
>
>>
>> Now, when the next set of messages come in(which is not over http), I
>> would need to intercept these and add my handling(ideally write
>> something on the socket on which the message came and be done with the
>> request while keeping the connection persistent unless the message was
>> a control frame to close).
>>
>> Regards,
>> Umapathy
>>
>>
>> On Fri, Sep 27, 2013 at 12:29 PM, Sorin Manolache <so...@gmail.com>
>> wrote:
>>>
>>> On 2013-09-27 03:06, Pon Umapathy Kailash S wrote:
>>>>
>>>>
>>>> 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?
>>>
>>>
>>>
>>> In my opinion, it is too late to handle non-http in the create_request
>>> callback.
>>>
>>> The create_request callback is called from
>>>
>>> ap_run_process_connection->ap_process_http_{sync|async}_connection->ap_read_request.
>>>
>>> Your create_request callback returns to ap_read_request from where the
>>> request is further processed as an http request.
>>>
>>> In my opinion you should short-cut the http processing and hook
>>> ap_hook_process_connection. However, there, in process_connection, you
>>> have
>>> no request_rec, you have just a conn_rec. process_connection is called
>>> only
>>> once per connection creation. So it should handle all the requests that
>>> arrive while the connection is open.
>>>
>>> Sorin
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Regards,
>>>> Umapathy
>>>>
>>>
>

Re: response handling inside ap_hook_create_request cb function

[Sorin Manolache <so...@gmail.com>]

On 2013-09-27 11:11, Pon Umapathy Kailash S wrote:
> Thanks for your response, Sorin.
>
> My concern in this approach is that - it would require one worker
> thread to be held up for as long as this connection is open(and this
> might be long + the number of clients can be higher than the worker
> threads for my use-case/platform).
>
> Given that the 1st handshake message is over http, i can setup the
> connection in a handler hookup function and return a response, freeing
> up the worker thread while keeping the connection persistent(plus save
> the socket/ssl in a cache shared the worker threads).

Anyway in "normal" apache, i.e. over http, the worker threads are not 
freed up after processing a request. An idle worker thread is assigned 
to a connection when one is opened by a client for the whole duration of 
the connection. You can check that in 
modules/http/http_core.c:ap_process_http_sync_connection. You'll see 
that ap_process_request is called in a loop. The loop is left when the 
connection is closed. If the connection is idle, the worker thread is in 
"KeepAlive" state. You can check this when looking at /server-status.

So it would not make any difference if you assigned a worker to the 
connection in process_connection.

You'll have to take care though not to overuse the connection memory 
pool because the pool is not destroyed while the connection is open, and 
this could be a long time.

>
> Now, when the next set of messages come in(which is not over http), I
> would need to intercept these and add my handling(ideally write
> something on the socket on which the message came and be done with the
> request while keeping the connection persistent unless the message was
> a control frame to close).
>
> Regards,
> Umapathy
>
>
> On Fri, Sep 27, 2013 at 12:29 PM, Sorin Manolache <so...@gmail.com> wrote:
>> On 2013-09-27 03:06, Pon Umapathy Kailash S wrote:
>>>
>>> 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?
>>
>>
>> In my opinion, it is too late to handle non-http in the create_request
>> callback.
>>
>> The create_request callback is called from
>> ap_run_process_connection->ap_process_http_{sync|async}_connection->ap_read_request.
>>
>> Your create_request callback returns to ap_read_request from where the
>> request is further processed as an http request.
>>
>> In my opinion you should short-cut the http processing and hook
>> ap_hook_process_connection. However, there, in process_connection, you have
>> no request_rec, you have just a conn_rec. process_connection is called only
>> once per connection creation. So it should handle all the requests that
>> arrive while the connection is open.
>>
>> Sorin
>>
>>
>>
>>
>>
>>>
>>> Regards,
>>> Umapathy
>>>
>>

Re: response handling inside ap_hook_create_request cb function

[Pon Umapathy Kailash S <po...@gmail.com>]

Thanks for your response, Sorin.

My concern in this approach is that - it would require one worker
thread to be held up for as long as this connection is open(and this
might be long + the number of clients can be higher than the worker
threads for my use-case/platform).

Given that the 1st handshake message is over http, i can setup the
connection in a handler hookup function and return a response, freeing
up the worker thread while keeping the connection persistent(plus save
the socket/ssl in a cache shared the worker threads).

Now, when the next set of messages come in(which is not over http), I
would need to intercept these and add my handling(ideally write
something on the socket on which the message came and be done with the
request while keeping the connection persistent unless the message was
a control frame to close).

Regards,
Umapathy


On Fri, Sep 27, 2013 at 12:29 PM, Sorin Manolache <so...@gmail.com> wrote:
> On 2013-09-27 03:06, Pon Umapathy Kailash S wrote:
>>
>> 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?
>
>
> In my opinion, it is too late to handle non-http in the create_request
> callback.
>
> The create_request callback is called from
> ap_run_process_connection->ap_process_http_{sync|async}_connection->ap_read_request.
>
> Your create_request callback returns to ap_read_request from where the
> request is further processed as an http request.
>
> In my opinion you should short-cut the http processing and hook
> ap_hook_process_connection. However, there, in process_connection, you have
> no request_rec, you have just a conn_rec. process_connection is called only
> once per connection creation. So it should handle all the requests that
> arrive while the connection is open.
>
> Sorin
>
>
>
>
>
>>
>> Regards,
>> Umapathy
>>
>

Re: response handling inside ap_hook_create_request cb function

[Sorin Manolache <so...@gmail.com>]

On 2013-09-27 03:06, Pon Umapathy Kailash S wrote:
> 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?

In my opinion, it is too late to handle non-http in the create_request 
callback.

The create_request callback is called from 
ap_run_process_connection->ap_process_http_{sync|async}_connection->ap_read_request.

Your create_request callback returns to ap_read_request from where the 
request is further processed as an http request.

In my opinion you should short-cut the http processing and hook 
ap_hook_process_connection. However, there, in process_connection, you 
have no request_rec, you have just a conn_rec. process_connection is 
called only once per connection creation. So it should handle all the 
requests that arrive while the connection is open.

Sorin





>
> Regards,
> Umapathy
>

Re: response handling inside ap_hook_create_request cb function

[Pon Umapathy Kailash S <po...@gmail.com>]

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
<ro...@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 <po...@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
>> <ro...@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 <po...@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

Re: response handling inside ap_hook_create_request cb function

[Robert Mitschke <ro...@ebeesmarttechnologies.de>]

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 <po...@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
> <ro...@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 <po...@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

Re: response handling inside ap_hook_create_request cb function

[Pon Umapathy Kailash S <po...@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
<ro...@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 <po...@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