[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Commands using the HTTP adapter
|
> -----Original Message-----
> From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On
> Behalf Of Hudalla Kai (INST/ECS4)
> Sent: Montag, 7. Mai 2018 11:09
> To: hono-dev@xxxxxxxxxxx
> Subject: 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?
FMPOV the protocol adapter never knows which application to wait for - it just delays the response by the timeToDeliver
parameter and then finally answers it.
Or answers it much quicker if it received a message via the AMQP 1.0 command link that was opened for the device.
And if there is a possibility to not only send a command via this link, but also that there is "no command waiting", the adapter can answer the request directly
after it received this.
How this would be used by applications is transparent for us, we would only offer a message format for signaling "there is no command now" (specific content-type for
commands e.g.).
If a command was provided, it will close the request also - without considering if there were "more" applications that would also like to send a command.
That was the idea (as future extension).
> > _______________________________________________
> > 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
> _______________________________________________
> 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
