Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Commands using the HTTP adapter 
> > This would improve the current implementation a lot IMHO (since we can
> > configure tenants where usually downstream messages with ttd are
> > always anwered fast), but I ask myself why this would address your concerns?
> >
> > Since the applications that may send such a "no command-message" are
> > bound to the tenant of the device that sent a downstream message with
> > time-til- disconnect parameter, we still have the same situation:
> > - one application of the tenant sends the "no command-message" (in
> > reaction to downstream message), the PA closes the request with a
> > quick answer then
> > - other applications may have some commands that they would like to
> > send, but they cannot do this since they are not being informed
> >
> 
> In cases where this behavior makes sense, i.e. there only exists one consuming
> application for the devices of the tenant, the organization's "tenant manager"
> will know about this fact and can set the option. Otherwise, default behavior is
> applied ...

IMHO why not just always support the "no command-message"?

If a "tenant manager" knows that it does not want the immediate response to a request, the applications (that belong to himself)
would just not send the "no command-message". And then the PA will wait until ttd expired, giving the chance to other application instances
to send a command during this time frame.

So, no extra tenant-parameter - just use the "no command-message" inside the applications belonging to the tenant,
or _not_ use it.

Would you agree to this?

Otherwise I can live well with the tenant configuration, too - to me it just seems to introduce a config parameter that is for now not really enabling (or preventing) new patterns.

> 
> >
> > > -----Original Message-----
> > > From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On
> > > Behalf Of Hudalla Kai (INST/ECS4)
> > > Sent: Mittwoch, 13. Juni 2018 08:06
> > > To: hono-dev@xxxxxxxxxxx
> > > Subject: 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
> > >
> > > _______________________________________________
> > > 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

Back to the top