[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Commands using the HTTP adapter
|
On Fri, 2018-04-27 at 09:48 +0000, Frank Karsten (INST/ECS4) wrote:
> Hi all,
>
> I like to shortly discuss the way we handle sending a command via HTTP back to
> a device.
>
> We now have an almost merged solution for devices setting their "ttd" (time til
> disconnect) by adding an HTTP header
> (or query param) to any downstream message.
> The question is how the HTTP adapter itself treats the "ttd".
>
> Scenario:
>
> 1.) the prototyped working version of the HTTP adapter delays the HTTP response
> by the number of seconds passed via "ttd"
> to give an application the chance to send a command upstream
>
> 2.) an application receiving the downstream message evaluates the "ttd" and may
> or may not send a command (by using
> the AMQP 1.0 link that was opened for the device)
>
> 3.) if there was a command, the HTTP adapter adds the command (received from
> the application) to the HTTP response and answers the HTTP request
> 4.) if there was no command, the HTTP adapter waits until "ttd" is expired and
> then answers the HTTP request
>
> So far, so good.
>
>
> The "problem" I like to discuss is that I have some concerns about the HTTP
> response delay:
>
> Looking at step 3.) and 4.) and the expectation that commands are much less
> frequent than downstream messages, it would result in
>
> 3.) results in a quick answer
>
> 4.) results in a long delayed answer (will take the whole number of seconds
> that were specified by "ttd")
>
>
> My feeling is we should have some information from the receiving application if
> there is NO command as well, not only if there IS a command.
>
I do not see how we could accomplish this, given that Hono cannot know which
applications would potentially send a command.
> Proposal:
>
> To get a first version implemented we should nevertheless implement it like
> outlined above, and clearly emphasize this behaviour in the
> documentation by giving some setup recommendations, like:
>
> - devices rarely sending downstream messages may always set the "ttd" and live
> with the fact that the responses are most of the time delayed by this value
>
> - devices often sending downstream messages should better use the introduced
> "empty event" to indicate every once in a while that they are ready for a
> command,
> but NOT do this for every downstream message
>
sounds reasonable
>
> - later we can search for a way to inform the adapter that there is NO command
> (or we find another solution)
>
In fact, I do not consider this to be a real problem because devices can choose
from the two options you outlined above in order to suit their needs.
>
> All is only affecting the HTTP adapter (due to the request/response pattern).
>
This also affects e.g. the MQTT adapter if the device follows a pattern of
- wake up
- connect
- send data
- disconnect
- got to sleep
>
> Any opinions on that?
>
> Thanks,
> Karsten
>
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/hono-dev
