[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Commands using the HTTP adapter
|
On Mon, 2018-05-07 at 08:37 +0000, Frank Karsten (INST/ECS4) wrote:
> Thanks for the response, Kai - see my answers inline below...
>
> > >
> > >
> > > 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.
>
> We could offer the application a way to inform the adapter that there is no
> command, so the
> Adapter can answer the device request quickly without having to wait for the
> timeout.
>
> Would consider this:
> - future extension (not for M6)
> - being optional to use it from the application
>
My point is: how does the protocol adapter know, which applications it should
wait for? Getting a NACK from one application does not necessarily mean that no
other application wants to send a command does it? In the end you will (again)
need to define an arbitrary timeout at the protocol adapter after which it stops
waiting for NACKs from other applications. So, we end up where we started, right?
> >
> >
> > > 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
>
> Fine, so that will be the implementation resp. documentation for M6 then.
>
> > >
> > > 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
>
> That is true for this pattern.
>
>
> _______________________________________________
> 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
