[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Commands using the HTTP adapter
|
On Wed, 2018-05-09 at 09:42 +0000, Frank Karsten (INST/ECS4) wrote:
> > -----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.
>
Of course, I understand the benefit of the intention.
> 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.).
>
And this is where we seem to disagree. I do not think that we can simply "let any
application send the no-command message" and then send the (empty) response to
the device, because we have no control over which and how many applications will
actually be involved. This mainly depends on the implementation and capabilities
of the AMQP network. However, we could add a configuration option at the tenant
level (i.e. to be configured in the Tenant service) which would allow a protocol
adapter to take such a "no-command" message at face value and end the device's
request. If this option is not configured for a tenant, then the adapter would
behave as usual and wait for the TTD to expire. WDYT?
> 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
>
> _______________________________________________
> 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
